REVERSE the AGING PROCESS 10-20 Years!
Younger@bdsm.at Thu, 30 November 2000 23:57 UTC
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09565 for <pkix-archive@odin.ietf.org>; Thu, 30 Nov 2000 18:57:20 -0500 (EST)
Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA24955; Thu, 30 Nov 2000 15:55:01 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 30 Nov 2000 15:54:51 -0800
Received: from mail.governacio-ri.gencat.es (gencat.es [194.179.95.227]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24923 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 15:54:50 -0800 (PST)
Date: Thu, 30 Nov 2000 15:54:50 -0800
From: Younger@bdsm.at
Message-Id: <200011302354.PAA24923@ns.secondary.com>
Received: from aks011 (1Cust54.tnt1.mia5.da.uu.net [63.30.194.54]) by mail.governacio-ri.gencat.es with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id X8T2JX77; Fri, 1 Dec 2000 00:55:22 +0100
To: Younger@bdsm.at
Subject: REVERSE the AGING PROCESS 10-20 Years!
MIME-Version: 1.0
Content-Type: text/plain; charset="unknown-8bit"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe
HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)???
Released by your own pituitary gland, HGH starts
declining in your 20s, even more in your 30s and 40s,
eventually resulting in the shrinkage of major
organs-plus all other symptoms related to old age.
THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL
STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING:
* Reduce Body Fat Without Dieting
Build Lean Muscle WITHOUT EXERCISE!
* Enhance Sexual Performance
* Remove Wrinkles and Cellulite
* Lower Blood Pressure and improve Cholesterol Profile
* Improve Sleep, Vision and Memory
* Restore Hair Color and Growth
* Strengthen the Immune System
* Increase Energy and Cardiac Output
* Turn back your body's Biological Time Clock 10-20
years in 6 months of usage !!!
You don't have to spend thousands of dollars on shots.
You don't have to spend the $139.00 per bottle that
HGH is selling for at some Clinics in the
United States.
For the next 30 Days, you can obtain a complete
one-month supply of our HGH releaser for our special
"New Customers" price of just $69.95 plus $6.00
shipping and handling. To ensure a constant supply and
to SAVE EVEN MORE, you can order with confidence
3 bottles of HGH and GET 1 FREE - that's just $209.85 for
4 bottles, plus $6.00 shipping and handling.
You SAVE $69.95! ORDER TODAY!
Payment Methods
You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express payments. Money Orders
are accepted only by Postal Mail.
Step 1: Place a check by your desired quanity.
______ 1 Bottle of HGH $69.95
______ 2 Bottles of HGH $131.90 ($65.95 a bottle)
______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85
Please add $6 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ]
International shipping, please add $35 for any size order
[ Total cost including shipping & handling,
1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ]
Foreign checks are not accepted. Credit cards & international
money orders only.
Step 2: Place a check by your desired payment method
and complete fields if necessary.
_____Check or CHECK-BY-FAX [details below]
_____Money Order
_____American Express
Account Number__________________ Exp____/____
_____Visa
Account Number__________________ Exp____/____
_____MasterCard
Account Number__________________ Exp____/____
Please make your check or money order payable to
"Lion Sciences National".
Step 3: Please complete and print the following fields clearly.
Name ___________________________________________________
Address _________________________________________________
City ____________________________________________________
State ___________________________________________________
Zip _____________________________________________________
E-mail __________________________________________________
Signature _________________________________________________
[ required for check and credit card orders]
Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all.
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.
Or, print & mail to:
Lion Sciences National
273 S. State Rd. 7 #193
Margate, FL 33068-5727
______________________________________________________
*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !
TAPE CHECK BELOW
_____________________________________________________________
This is a one time mailing: Removal is automatic and no further
contact is necessary. Please Note: HGH is not intended to
diagnose, treat, cure or prevent any disease. The FDA has not
evaluated these statements.
Received: from mail.governacio-ri.gencat.es (gencat.es [194.179.95.227]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24923 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 15:54:50 -0800 (PST)
Date: Thu, 30 Nov 2000 15:54:50 -0800 (PST)
From: Younger@bdsm.at
Message-Id: <200011302354.PAA24923@ns.secondary.com>
Received: from aks011 (1Cust54.tnt1.mia5.da.uu.net [63.30.194.54]) by mail.governacio-ri.gencat.es with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id X8T2JX77; Fri, 1 Dec 2000 00:55:22 +0100
To: Younger@bdsm.at
Subject: REVERSE the AGING PROCESS 10-20 Years!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)???
Released by your own pituitary gland, HGH starts
declining in your 20s, even more in your 30s and 40s,
eventually resulting in the shrinkage of major
organs-plus all other symptoms related to old age.
THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL
STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING:
* Reduce Body Fat Without Dieting
Build Lean Muscle WITHOUT EXERCISE!
* Enhance Sexual Performance
* Remove Wrinkles and Cellulite
* Lower Blood Pressure and improve Cholesterol Profile
* Improve Sleep, Vision and Memory
* Restore Hair Color and Growth
* Strengthen the Immune System
* Increase Energy and Cardiac Output
* Turn back your body's Biological Time Clock 10-20
years in 6 months of usage !!!
You don't have to spend thousands of dollars on shots.
You don't have to spend the $139.00 per bottle that
HGH is selling for at some Clinics in the
United States.
For the next 30 Days, you can obtain a complete
one-month supply of our HGH releaser for our special
"New Customers" price of just $69.95 plus $6.00
shipping and handling. To ensure a constant supply and
to SAVE EVEN MORE, you can order with confidence
3 bottles of HGH and GET 1 FREE - that's just $209.85 for
4 bottles, plus $6.00 shipping and handling.
You SAVE $69.95! ORDER TODAY!
Payment Methods
You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express payments. Money Orders
are accepted only by Postal Mail.
Step 1: Place a check by your desired quanity.
______ 1 Bottle of HGH $69.95
______ 2 Bottles of HGH $131.90 ($65.95 a bottle)
______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85
Please add $6 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ]
International shipping, please add $35 for any size order
[ Total cost including shipping & handling,
1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ]
Foreign checks are not accepted. Credit cards & international
money orders only.
Step 2: Place a check by your desired payment method
and complete fields if necessary.
_____Check or CHECK-BY-FAX [details below]
_____Money Order
_____American Express
Account Number__________________ Exp____/____
_____Visa
Account Number__________________ Exp____/____
_____MasterCard
Account Number__________________ Exp____/____
Please make your check or money order payable to
"Lion Sciences National".
Step 3: Please complete and print the following fields clearly.
Name ___________________________________________________
Address _________________________________________________
City ____________________________________________________
State ___________________________________________________
Zip _____________________________________________________
E-mail __________________________________________________
Signature _________________________________________________
[ required for check and credit card orders]
Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all.
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.
Or, print & mail to:
Lion Sciences National
273 S. State Rd. 7 #193
Margate, FL 33068-5727
______________________________________________________
*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !
TAPE CHECK BELOW
_____________________________________________________________
This is a one time mailing: Removal is automatic and no further
contact is necessary. Please Note: HGH is not intended to
diagnose, treat, cure or prevent any disease. The FDA has not
evaluated these statements.
Received: from uswimil00im001.tmp.com (mil-fw1g.tmp.com [63.144.121.251]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA21238 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 14:18:54 -0800 (PST)
Received: by USWIMIL00IM001 with Internet Mail Service (5.5.2650.21) id <XDT9WJ33>; Thu, 30 Nov 2000 16:15:16 -0600
Message-ID: <87AF8B39CD89D41196C500B0D049726A01B054A4@USFLTAM00IS001>
From: "Pierce, Shirley" <shirley.pierce@tmp.com>
To: "'Heidi Kay'" <heidi@kayconcepts.com>, ietf-pkix@imc.org
Subject: RE: please help in my search
Date: Thu, 30 Nov 2000 16:13:57 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Heidi,
I am looking for PKI developers in Dallas, Texas as well. If you have any
candidates that will not take the opportunity in Ohio but willing to work in
Dallas, I have a full-time position available.
Shirley Pierce
Executive Resourcing
972-354-2572
shirley.pierce@tmp.com
-----Original Message-----
From: Heidi Kay [mailto:heidi@kayconcepts.com]
Sent: Thursday, November 30, 2000 3:52 PM
To: ietf-pkix@imc.org
Subject: please help in my search
Hello,
I apologize in advance for intruding on this technical forum, but I was
hoping someone here could help me.
I am a technical recruiter looking for a software engineer with PKI and
other security background. My client is in the midwest and is an
excellent employer. I have placed 80 people with them.
Does anyone know, either who might be looking or where I might legitimately
post such a job description?
Here is the opening so that you know what I need. Thank you in
advance. I will not post to this group again.
Heidi Kay, President, Kay Concepts, Inc.
------------------------------------------------
Job Location:
Akron/Canton, OH
Job Summary:
We are on retainer with a premier Fortune high technology manufacturing
company that manufacturers self-service terminals for financial
applications (Automated Teller Machines)
Our client is growing and as a result has a need for a talented, Software
Engineer who has some expertise in Software Security and Cryptography.
This is a senior level software and systems engineering position. The
individual will be responsible for the investigation and implementation of
such software and hardware components that ensure the secure transfer and
storage of sensitive financial institution and individual customer data.
This will include, but not be limited to, transfer and holding of customer
PIN's cryptography keys and algorithms. The individual will provide input,
such as software algorithms, information on current industry trends, to
various internal software groups. Will ensure that algorithms and
techniques used for data security meet government and industry standards
specifications.
Qualifications
* A BSEE or BSCS or equivalent degree with 5 to 7 years of
programming experience
* Experience in cryptography and other PC security projects
* Experience with data communications standards and trends
* Experience with C, C++ and general software and system development
practices
* Experience in Windows NT, Windows 98, OS/2 required, Linux and Unix
helpful
>
Compensation/Benefits:
Salaries based on candidates experience level. Full
relocation and interview expenses provided.
Heidi Kay, CPC
Kay Concepts, Inc.
PO Box 4825, Palm Harbor, FL 34685
"Making the most of what you've made of yourself"
E-mail address: heidi@kayconcepts.com
URL: www.kayconcepts.com
PH: (800) 879-5850 Local: (727) 786-3580
FAX: (800) 879-5828 Toll: (208) 988-3822
Received: from smtp-server.tampabay.rr.com (smtp-server.tampabay.rr.com [65.32.1.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19401 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 13:57:24 -0800 (PST)
Received: from heidikay.kayconcepts.com (24161229hfc245.tampabay.rr.com [24.161.229.245]) by smtp-server.tampabay.rr.com (8.9.3/8.9.3) with ESMTP id QAA19284 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 16:59:00 -0500 (EST)
Message-Id: <4.3.2.7.2.20001130165137.00c22e70@pop-server>
X-Sender: hkay1@pop-server (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 30 Nov 2000 16:51:47 -0500
To: ietf-pkix@imc.org
From: Heidi Kay <heidi@kayconcepts.com>
Subject: please help in my search
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hello,
I apologize in advance for intruding on this technical forum, but I was
hoping someone here could help me.
I am a technical recruiter looking for a software engineer with PKI and
other security background. My client is in the midwest and is an
excellent employer. I have placed 80 people with them.
Does anyone know, either who might be looking or where I might legitimately
post such a job description?
Here is the opening so that you know what I need. Thank you in
advance. I will not post to this group again.
Heidi Kay, President, Kay Concepts, Inc.
------------------------------------------------
Job Location:
Akron/Canton, OH
Job Summary:
We are on retainer with a premier Fortune high technology manufacturing
company that manufacturers self-service terminals for financial
applications (Automated Teller Machines)
Our client is growing and as a result has a need for a talented, Software
Engineer who has some expertise in Software Security and Cryptography.
This is a senior level software and systems engineering position. The
individual will be responsible for the investigation and implementation of
such software and hardware components that ensure the secure transfer and
storage of sensitive financial institution and individual customer data.
This will include, but not be limited to, transfer and holding of customer
PIN's cryptography keys and algorithms. The individual will provide input,
such as software algorithms, information on current industry trends, to
various internal software groups. Will ensure that algorithms and
techniques used for data security meet government and industry standards
specifications.
Qualifications
* A BSEE or BSCS or equivalent degree with 5 to 7 years of
programming experience
* Experience in cryptography and other PC security projects
* Experience with data communications standards and trends
* Experience with C, C++ and general software and system development
practices
* Experience in Windows NT, Windows 98, OS/2 required, Linux and Unix
helpful
>
Compensation/Benefits:
Salaries based on candidates experience level. Full
relocation and interview expenses provided.
Heidi Kay, CPC
Kay Concepts, Inc.
PO Box 4825, Palm Harbor, FL 34685
"Making the most of what you've made of yourself"
E-mail address: heidi@kayconcepts.com
URL: www.kayconcepts.com
PH: (800) 879-5850 Local: (727) 786-3580
FAX: (800) 879-5828 Toll: (208) 988-3822
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18031; Thu, 30 Nov 2000 13:30:02 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA27184; Thu, 30 Nov 2000 13:27:37 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNFTPJ2L>; Thu, 30 Nov 2000 13:31:39 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154C71F@vhqpostal.verisign.com>
From: Philip Hallam-Baker <pbaker@verisign.com>
To: "'Paul Hoffman / IMC'" <phoffman@imc.org>, ietf-pkix@imc.org
Subject: RE: A new XMLPKI WG?
Date: Thu, 30 Nov 2000 13:31:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_005A_01C05AEB.3B4536A0"; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
This is a multi-part message in MIME format.
------=_NextPart_000_005A_01C05AEB.3B4536A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
> Hey! Something that Mike and I agree on. :-) If the work is kept
> within this WG, it will force the proposers to explain the value add
> for XML for the certificate and CRL and OCSP replacements. I, for
> one, would be interested in hearing those.
The XKMS proposal does not propose a certificate format, nor do
I believe that there is a value to any specification that merely
translates PKIX datastructures into XML. I do not want it here
or there, I do not want it anywhere. XKMS is not a PKI, it is an
interface to a trust infrastructure.
We have not proposed XKMS as a PKIX work item and do not intend to.
It will be a work item in some open standards body somewhere. It will
also have a significant relationship to many PKIX work items and many
PKIX people will be involved. However I also hope that some of the non
PKIX people whose sole or principle issue was hatred of ASN.1 would be
involved.
The reason I would like to present the work is that it is a significant
initiative in the PKI and Trust Infrastructure space and will certainly
affect the decisions of the working group when it comes to evaluate
future proposals for additional work items. The views of the group will
certainly be relevant as we move to make XKMS a standard, in particular
with respect to choice of forum.
Phill
------=_NextPart_000_005A_01C05AEB.3B4536A0
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ
AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx
MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s
IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf
/wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq
PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB
dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz
aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC
BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB
hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr
BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g
YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA
MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc
mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM
F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH
9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy
bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy
aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB
jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDExMzAyMTMzMTJa
MCMGCSqGSIb3DQEJBDEWBBSqtQQGej9Ony53WmKWQ4OvH8zXMzBYBgkqhkiG9w0BCQ8xSzBJMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl
MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN
BgkqhkiG9w0BAQEFAASBgBsKDRu+Mfg05s1wHgq8LUpBARqv1YfmKOUAIxsPCUuxxfW+BlEMgo1T
81RKGB1JWV75YWfqzf/21qQmyOwl5ZgbmLmwOogc1HpGeChOWQp4dd1ihD7WBkAYH4wwZm0XHYYC
YAIcvsyWf9umWQKeoy9FeWqUyMKoIiXxDIPpYP6HAAAAAAAA
------=_NextPart_000_005A_01C05AEB.3B4536A0--
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17401 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 13:22:51 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA26868; Thu, 30 Nov 2000 13:20:20 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNFTPJD4>; Thu, 30 Nov 2000 13:24:23 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BCE2@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: "Henry, Mike (Contr)" <MHENRY2@logicon.com>, "'David P. Kemp'" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: RE: A new XMLPKI WG?
Date: Thu, 30 Nov 2000 13:24:13 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
A superior answer to Kemp's but unfortunately I already acknowledged Dave's
Hemingway catch. Maybe you and he can share his $7 but that's between you
two of you.
Mike
Hint re: grapes. It was a guy who had a friend named Charley.
> -----Original Message-----
> From: Henry, Mike (Contr) [mailto:MHENRY2@logicon.com]
> Sent: Thursday, November 30, 2000 8:11 AM
> To: 'David P. Kemp'; ietf-pkix@imc.org
> Subject: RE: A new XMLPKI WG?
>
>
> Hemingway, A Moveable Feast, 1964 ???
>
> M. Henry
>
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17375 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 13:22:48 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA28758 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 13:26:02 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNF2KDA3>; Thu, 30 Nov 2000 13:24:22 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BCE4@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: ietf-pkix@imc.org
Subject: Marla Dans caught the LZ reference too
Date: Thu, 30 Nov 2000 13:24:19 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Just noticed that Marla Dans [Marla.Dans@msdw.com] also caught the LZ
reference but it came to me offlist. Sorry, Marla.
Mike
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15717; Thu, 30 Nov 2000 13:01:29 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailc.telia.com (8.11.0/8.11.0) with ESMTP id eAUL35s20680; Thu, 30 Nov 2000 22:03:05 +0100 (CET)
Received: from mega (t2o69p79.telia.com [62.20.144.199]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eAUL34o08390; Thu, 30 Nov 2000 22:03:04 +0100 (CET)
Message-ID: <002801c05b10$bb0efd60$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: <ietf-pkix@imc.org>, "Paul Hoffman / IMC" <phoffman@imc.org>
References: <2F3EC696EAEED311BB2D009027C3F4F401C5BC07@vhqpostal.verisign.com> <p050104a5b64b7b50506e@[165.227.249.17]>
Subject: Re: A new XMLPKI WG?
Date: Thu, 30 Nov 2000 22:01:36 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA15720
> At 7:23 PM -0800 11/29/00, Michael Myers wrote:
> >This feast may move but the song remains the same. I for one see no reason
> >for a new WG re: XML+PKI. It's just going to be the same people, the same
> >voices, etc. Would it not more effective to simply amend our existing
> >charter and motor on? Just a thought. In any event, $10US (ten dollars US)
> >out of my pocket to the first person who correctly identifies onlist the
> >references implied in the first sentence.
>
> Hey! Something that Mike and I agree on. :-) If the work is kept
> within this WG, it will force the proposers to explain the value add
> for XML for the certificate and CRL and OCSP replacements. I, for
> one, would be interested in hearing those.
Well Paul, If XMLPKI will look like the following extract from the SCVP
draft it will certainly fail.
<TypesOfCheck>
<ObjID>1.3.5.5.5.2.5.2</ObjID>
</TypesOfCheck>
<WantBack>
<ObjID>1.3.5.5.5.2.5.2</ObjID>
</WantBack>
Fortunately I don't think this is representative for much PKI-related things done in XML.
/Anders
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14670 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 12:49:44 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <XJNAQ286>; Thu, 30 Nov 2000 15:42:21 -0500
Message-ID: <DD62792EA182FF4E99C2FBC07E3053BD053EBB@sottmxs09.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: "'Ari Kermaier'" <arik@phaos.com>
Cc: ietf-pkix@imc.org
Subject: RE: draft-ietf-pkix-rfc2511bis-00
Date: Thu, 30 Nov 2000 15:51:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05B0F.48C96890"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C05B0F.48C96890
Content-Type: text/plain
Hi Ari,
RFC 2511 (and therefore rfc2511bis-00.txt) has the definitive syntax (the
section in 2510 discusses semantic interpretation). Therefore, publicKeyMAC
is untagged. I will try to remember to remove the tag from rfc2510bis as it
progresses.
Thanks for noticing this!
Carlisle.
> ----------
> From: Ari Kermaier[SMTP:arik@phaos.com]
> Sent: Thursday, November 30, 2000 2:20 PM
> To: ietf-pkix@imc.org
> Subject: RE: draft-ietf-pkix-rfc2511bis-00
>
> A question of ASN.1 in CRMF:
>
> draft-ietf-pkix-rfc2511bis-00 Section 4.4 has:
>
> POPOSigningKeyInput ::= SEQUENCE {
> authInfo CHOICE {
> sender [0] GeneralName,
> -- used only if an authenticated identity has been
> -- established for the sender (e.g., a DN from a
> -- previously-issued and currently-valid certificate)
> publicKeyMAC PKMACValue },
> -- used if no authenticated GeneralName currently exists for
> -- the sender; publicKeyMAC contains a password-based MAC
> -- on the DER-encoded value of publicKey
> publicKey SubjectPublicKeyInfo } -- from CertTemplate
>
> draft-ietf-pkix-rfc2510bis-01 Section 3.2.8 has:
>
> POPOSigningKeyInput ::= SEQUENCE {
> authInfo CHOICE {
> sender [0] GeneralName,
> -- from PKIHeader (used only if an authenticated identity
> -- has been established for the sender (e.g., a DN from a
> -- previously-issued and currently-valid certificate))
> publicKeyMAC [1] PKMACValue
> -- used if no authenticated GeneralName currently exists for
> -- the sender; publicKeyMAC contains a password-based MAC
> -- (using the protectionAlg AlgId from PKIHeader) on the
> -- DER-encoded value of publicKey
> },
> publicKey SubjectPublicKeyInfo -- from CertTemplate
> }
>
> So -- is the publicKeyMAC choice tagged or not?
>
> Ari Kermaier
>
------_=_NextPart_001_01C05B0F.48C96890
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: draft-ietf-pkix-rfc2511bis-00</TITLE>
</HEAD>
<BODY>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Ari,</FONT>
</P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">RFC 2511 =
(and therefore rfc2511bis-00.txt) has the definitive syntax (the =
section in 2510 discusses semantic interpretation). Therefore, =
publicKeyMAC is untagged. I will try to remember to remove the =
tag from rfc2510bis as it progresses.</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Thanks for =
noticing this!</FONT>
</P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Ari =
Kermaier[SMTP:arik@phaos.com]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Thursday, November 30, 2000 2:20 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">ietf-pkix@imc.org</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: draft-ietf-pkix-rfc2511bis-00</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">A question of ASN.1 in CRMF:</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">draft-ietf-pkix-rfc2511bis-00 Section =
4.4 has:</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial"> POPOSigningKeyInput =
::=3D SEQUENCE {</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> =
authInfo &nbs=
p; CHOICE {</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; =
sender =
[0] GeneralName,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- used only if an authenticated identity has been</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- established for the sender (e.g., a DN from a</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- previously-issued and currently-valid certificate)</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; publicKeyMAC =
PKMACValue },</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- used if no authenticated GeneralName currently exists =
for</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- the sender; publicKeyMAC contains a password-based =
MAC</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- on the DER-encoded value of publicKey</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> =
publicKey =
SubjectPublicKeyInfo } -- from CertTemplate</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">draft-ietf-pkix-rfc2510bis-01 Section =
3.2.8 has:</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial"> =
POPOSigningKeyInput ::=3D SEQUENCE {</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> =
authInfo &nbs=
p; CHOICE {</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; =
sender =
[0] GeneralName,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> &n=
bsp; -- from PKIHeader (used only =
if an authenticated identity</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- has been established for the sender (e.g., a =
DN from a</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- previously-issued and currently-valid =
certificate))</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; =
publicKeyMAC [1] =
PKMACValue</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- used if no authenticated GeneralName currently =
exists for</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- the sender; publicKeyMAC contains a =
password-based MAC</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- (using the protectionAlg AlgId from PKIHeader) =
on the</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> &nb=
sp; -- DER-encoded value of publicKey</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> =
},</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial"> =
publicKey =
SubjectPublicKeyInfo -- from CertTemplate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> =
}</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">So -- is the publicKeyMAC choice =
tagged or not?</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Ari Kermaier</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C05B0F.48C96890--
Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08100 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 11:11:54 -0800 (PST)
Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id SAA41510 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 18:04:45 -0500 (EST) (envelope-from arik@phaos.com)
Message-Id: <4.2.0.58.20001130141517.00c09100@mail.phaos.com>
X-Sender: arik@mail.phaos.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Thu, 30 Nov 2000 14:20:05 -0500
To: ietf-pkix@imc.org
From: Ari Kermaier <arik@phaos.com>
Subject: RE: draft-ietf-pkix-rfc2511bis-00
In-Reply-To: <918C70B01822D411A87400B0D0204DFF72F534@panda.chrysalis-its .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
A question of ASN.1 in CRMF:
draft-ietf-pkix-rfc2511bis-00 Section 4.4 has:
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
draft-ietf-pkix-rfc2510bis-01 Section 3.2.8 has:
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- from PKIHeader (used only if an authenticated identity
-- has been established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate))
publicKeyMAC [1] PKMACValue
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- (using the protectionAlg AlgId from PKIHeader) on the
-- DER-encoded value of publicKey
},
publicKey SubjectPublicKeyInfo -- from CertTemplate
}
So -- is the publicKeyMAC choice tagged or not?
Ari Kermaier
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04517 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 10:40:46 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA17430 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 10:38:15 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNFTP1W4>; Thu, 30 Nov 2000 10:42:18 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BCC4@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: ietf-pkix@imc.org
Subject: And the winners are . . .
Date: Thu, 30 Nov 2000 10:42:07 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
$3 to Carlisle for the Led Zepplin reference and $7 to Dave Kemp for
Hemingway because the Hemingway was the harder of the two. Honorable
mention to Mike Just and Sue Miklos for their off-list LZ catches.
Now, if I can just figure something to do with all these grapes . . . .
Mike
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04482; Thu, 30 Nov 2000 10:40:40 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA17562; Thu, 30 Nov 2000 10:43:48 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNF2KA3B>; Thu, 30 Nov 2000 10:42:11 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BCC3@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Paul Hoffman / IMC <phoffman@imc.org>, ietf-pkix@imc.org
Subject: RE: A new XMLPKI WG?
Date: Thu, 30 Nov 2000 10:42:06 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
I should clarify that XMLPKI needs may be better served by another forum,
but if IETF wants to do something about it, I don't see any reason for a new
WG but maybe somebody else does.
Mike
> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:phoffman@imc.org]
> Sent: Wednesday, November 29, 2000 7:38 PM
> To: ietf-pkix@imc.org
> Subject: Re: A new XMLPKI WG?
>
>
> At 7:23 PM -0800 11/29/00, Michael Myers wrote:
> >This feast may move but the song remains the same. I for
> one see no reason
> >for a new WG re: XML+PKI. It's just going to be the same
> people, the same
> >voices, etc. Would it not more effective to simply amend
> our existing
> >charter and motor on? Just a thought. In any event, $10US
> (ten dollars US)
> >out of my pocket to the first person who correctly
> identifies onlist the
> >references implied in the first sentence.
>
> Hey! Something that Mike and I agree on. :-) If the work is kept
> within this WG, it will force the proposers to explain the value add
> for XML for the certificate and CRL and OCSP replacements. I, for
> one, would be interested in hearing those.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03475 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 10:20:05 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA39946; Thu, 30 Nov 2000 19:27:52 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id TAA15068; Thu, 30 Nov 2000 19:21:06 +0100
Message-ID: <3A269A8F.4F0320BB@bull.net>
Date: Thu, 30 Nov 2000 19:21:03 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
CC: Michael Myers <MMyers@verisign.com>, ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <2F3EC696EAEED311BB2D009027C3F4F401C5BAB6@vhqpostal.verisign.com> <v04220814b649f5db23f4@[171.78.30.107]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Steve,
(Text deleted)
> I think there is ample support and technical rationale for this
> change, but it's significant enough to reset advancement for the OCSP
> document, i.e., v2 is a new standard.
i.e. a new protocol, not compatible with v1. Originally v2 was presented as
a refinement of v1, but it is not.
> You'll have to decide if it
> supercedes v1, etc. I'm awfully far behind on my e-mail.
Thank you for paying attention to this important aspect.
> so maybe
> I've missed this part of the debate, but what are the plans re OCSP
> v1, i.e., since we all loathe parallel, mostly equivalent versions of
> standards, is the proposal to replace v1 with v2, and denigrate the
> use of v1?
Mike's position is that v2 replaces v1. This would make all current v2
implementations obsolete and incompatible, hence why I have some concerns.
> Just asking ...
Good question. :-)
Denis
> Steve
Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27987 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 08:26:01 -0800 (PST)
From: FRousseau@chrysalis-its.com
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <XXCGX4HH>; Thu, 30 Nov 2000 11:27:35 -0500
Message-ID: <918C70B01822D411A87400B0D0204DFF72F534@panda.chrysalis-its.com>
To: ietf-pkix@imc.org
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2511bis-00.txt
Date: Thu, 30 Nov 2000 11:27:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05AEA.729080B6"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C05AEA.729080B6
Content-Type: text/plain;
charset="iso-8859-1"
Since the same comment that had previously been added in rfc2510bis for
clarifying when the EncryptedValue is used to carry a private key was also
added in this Internet Draft, PKCS#11 and ANSI X9.42 should probably be
added as references in this document.
Note also that the next draft of PKCS#11 v2.11 will include explicit support
for the ANSI X9.42 flavour of Diffie-Hellman and the wrapping (i.e.
encryption) of X9.42 Diffie-Hellman private keys. Therefore the exception
that the D-H algorithm OID and parameters MUST be as defined in ANSI X9.42
might soon become superfluous.
Cheers,
Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com Fax. (613) 723-5078
------_=_NextPart_001_01C05AEA.729080B6
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-rfc2511bis-00.txt</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Since the same comment that had previously been added =
in rfc2510bis for clarifying when the EncryptedValue is used to carry a =
private key was also added in this Internet Draft, PKCS#11 and ANSI =
X9.42 should probably be added as references in this =
document.</FONT></P>
<P><FONT SIZE=3D2>Note also that the next draft of PKCS#11 v2.11 will =
include explicit support for the ANSI X9.42 flavour of Diffie-Hellman =
and the wrapping (i.e. encryption) of X9.42 Diffie-Hellman private =
keys. Therefore the exception that the D-H algorithm OID and =
parameters MUST be as defined in ANSI X9.42 might soon become =
superfluous.</FONT></P>
<P><FONT SIZE=3D2>Cheers,</FONT>
</P>
<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>frousseau@chrysalis-its.com Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A> &nbs=
p; Fax. (613) 723-5078</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C05AEA.729080B6--
Received: from xcgca811.corp.logicon.com (xcgca811.corp.logicon.com [137.51.212.181]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA26967 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 08:10:26 -0800 (PST)
Received: from 137.51.212.181 by xcgca811.corp.logicon.com (InterScan E-Mail VirusWall NT); Thu, 30 Nov 2000 08:11:16 -0800 (Pacific Standard Time)
Received: by xcgca811.corp.logicon.com with Internet Mail Service (5.5.2650.21) id <XL3XDQ2H>; Thu, 30 Nov 2000 08:11:16 -0800
Message-ID: <B9D2C50DB437D21191940008C7B198F205A805C8@xcgva006>
From: "Henry, Mike (Contr)" <MHENRY2@logicon.com>
To: "'David P. Kemp'" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: RE: A new XMLPKI WG?
Date: Thu, 30 Nov 2000 08:10:38 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Hemingway, A Moveable Feast, 1964 ???
M. Henry
-----Original Message-----
From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
Sent: Thursday, November 30, 2000 09:58 AM
To: ietf-pkix@imc.org
Subject: Re: A new XMLPKI WG?
Hemingway.
> From: Michael Myers <MMyers@verisign.com>
> To: PKIX-List <ietf-pkix@imc.org>
> Subject: A new XMLPKI WG?
> Date: Wed, 29 Nov 2000 19:23:18 -0800
>
> All,
>
> This feast may move but the song remains the same. I for one see no
reason
> for a new WG re: XML+PKI. It's just going to be the same people, the same
> voices, etc. Would it not more effective to simply amend our existing
> charter and motor on? Just a thought. In any event, $10US (ten dollars
US)
> out of my pocket to the first person who correctly identifies onlist the
> references implied in the first sentence.
>
> Mike
>
>
> ____________________________________________________
> This confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> ____________________________________________________
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19635 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 07:25:14 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <W5KZL6YC>; Thu, 30 Nov 2000 10:27:06 -0500
Message-ID: <DD62792EA182FF4E99C2FBC07E3053BD053EB1@sottmxs09.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: "'David P. Kemp'" <dpkemp@missi.ncsc.mil>
Cc: ietf-pkix@imc.org
Subject: RE: A new XMLPKI WG?
Date: Thu, 30 Nov 2000 10:26:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05AE1.F2FD6C90"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C05AE1.F2FD6C90
Content-Type: text/plain
Don't forget Led Zeppelin. :-)
> ----------
> From: David P. Kemp[SMTP:dpkemp@missi.ncsc.mil]
> Reply To: David P. Kemp
> Sent: Thursday, November 30, 2000 9:58 AM
> To: ietf-pkix@imc.org
> Subject: Re: A new XMLPKI WG?
>
> Hemingway.
>
>
> > From: Michael Myers <MMyers@verisign.com>
> > To: PKIX-List <ietf-pkix@imc.org>
> > Subject: A new XMLPKI WG?
> > Date: Wed, 29 Nov 2000 19:23:18 -0800
> >
> > All,
> >
> > This feast may move but the song remains the same. I for one see no
> reason
> > for a new WG re: XML+PKI. It's just going to be the same people, the
> same
> > voices, etc. Would it not more effective to simply amend our existing
> > charter and motor on? Just a thought. In any event, $10US (ten dollars
> US)
> > out of my pocket to the first person who correctly identifies onlist the
> > references implied in the first sentence.
> >
> > Mike
> >
> >
> > ____________________________________________________
> > This confirms that this email message has been swept by
> > MIMEsweeper for the presence of computer viruses.
> > ____________________________________________________
>
------_=_NextPart_001_01C05AE1.F2FD6C90
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: A new XMLPKI WG?</TITLE>
</HEAD>
<BODY>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Don't =
forget Led Zeppelin. :-)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">David P. =
Kemp[SMTP:dpkemp@missi.ncsc.mil]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Reply To:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">David P. Kemp</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Thursday, November 30, 2000 9:58 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">ietf-pkix@imc.org</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: A new XMLPKI WG?</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Hemingway.</FONT>
</P>
<BR>
<P><FONT SIZE=3D2 FACE=3D"Arial">> From: Michael Myers =
<MMyers@verisign.com></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> To: PKIX-List =
<ietf-pkix@imc.org></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Subject: A new XMLPKI WG?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Date: Wed, 29 Nov 2000 19:23:18 =
-0800</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> All,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> This feast may move but the song =
remains the same. I for one see no reason</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> for a new WG re: XML+PKI. =
It's just going to be the same people, the same</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> voices, etc. Would it not =
more effective to simply amend our existing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> charter and motor on? Just =
a thought. In any event, $10US (ten dollars US)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> out of my pocket to the first =
person who correctly identifies onlist the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> references implied in the first =
sentence.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Mike</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> =
____________________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> This confirms that this email =
message has been swept by</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> MIMEsweeper for the presence of =
computer viruses.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> =
____________________________________________________</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C05AE1.F2FD6C90--
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16704 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 07:05:10 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA19992 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 09:41:54 -0500 (EST)
Message-Id: <200011301441.JAA19903@roadblock.missi.ncsc.mil>
Date: Thu, 30 Nov 2000 09:58:26 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: A new XMLPKI WG?
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: OkTEMoM5qTBNNfuR/brqbA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Hemingway.
> From: Michael Myers <MMyers@verisign.com>
> To: PKIX-List <ietf-pkix@imc.org>
> Subject: A new XMLPKI WG?
> Date: Wed, 29 Nov 2000 19:23:18 -0800
>
> All,
>
> This feast may move but the song remains the same. I for one see no reason
> for a new WG re: XML+PKI. It's just going to be the same people, the same
> voices, etc. Would it not more effective to simply amend our existing
> charter and motor on? Just a thought. In any event, $10US (ten dollars US)
> out of my pocket to the first person who correctly identifies onlist the
> references implied in the first sentence.
>
> Mike
>
>
> ____________________________________________________
> This confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> ____________________________________________________
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04489 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 03:48:13 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA19742; Thu, 30 Nov 2000 12:55:58 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA21044; Thu, 30 Nov 2000 12:49:13 +0100
Message-ID: <3A263EBC.FAAB78F0@bull.net>
Date: Thu, 30 Nov 2000 12:49:16 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
CC: MMyers@verisign.com, ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <200011301120.MAA02695@emeriau.edelweb.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter,
> > Rather easy. OCSP server may use any information they wish (e.g. a private
> > access to a database of the non revoked certificates from the CA (if this
> > exists) or CRLs). Howveer, since the requester wants the same kind of
> > response whatever source of information is being used, only the common
> > denominator of that information should be used to produce the response. In
> > particular there should be no assumption that the OCSP server, * for a
> > revocation status query *, has access to more information than the one
> > contained in a CRL.
> >
>
> Are you saying that a responder MUST respond 'good'
Certainly not. Thank you for raising the point which highlights that fact
that "good" as a response which is not appropriate. Before telling what is
the appropriate response, it is nice to remember what the question was. :-)
The question was: " What is the revocation status of this certificate ?"
There are only three possible answers : "revoked", "not revoked" or "don't
know".
Denis
>even if it has
> access to the actual cert database and knows that the cert does not
> exists.
>
> I think the responder would respond 'unknown' in this case.
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02402 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 03:19:07 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA02822; Thu, 30 Nov 2000 12:20:38 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 30 Nov 2000 12:20:38 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id MAA20286; Thu, 30 Nov 2000 12:20:37 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA02695; Thu, 30 Nov 2000 12:20:36 +0100 (MET)
Date: Thu, 30 Nov 2000 12:20:36 +0100 (MET)
Message-Id: <200011301120.MAA02695@emeriau.edelweb.fr>
To: MMyers@verisign.com, Denis.Pinkas@bull.net
Subject: Re: OCSP identifiers
Cc: ietf-pkix@imc.org
>
> Rather easy. OCSP server may use any information they wish (e.g. a private
> access to a database of the non revoked certificates from the CA (if this
> exists) or CRLs). Howveer, since the requester wants the same kind of
> response whatever source of information is being used, only the common
> denominator of that information should be used to produce the response. In
> particular there should be no assumption that the OCSP server, * for a
> revocation status query *, has access to more information than the one
> contained in a CRL.
>
Are you saying that a responder MUST respond 'good' even if it has
access to the actual cert database and knows that the cert does not
exists.
I think the responder would respond 'unknown' in this case.
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27531 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 02:55:57 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28182; Thu, 30 Nov 2000 05:57:29 -0500 (EST)
Message-Id: <200011301057.FAA28182@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-rfc2511bis-00.txt
Date: Thu, 30 Nov 2000 05:57:29 -0500
Sender: nsyracus@cnri.reston.va.us
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
Title : Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)
Author(s) : D. Solo, D. Kemp
Filename : draft-ietf-pkix-rfc2511bis-00.txt
Pages : 25
Date : 29-Nov-00
This document describes the Certificate Request Message Format
(CRMF). 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 associated registration
information.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-00.txt
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-rfc2511bis-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:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-rfc2511bis-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="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001129114616.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc2511bis-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-rfc2511bis-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001129114616.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26760 for <ietf-pkix@imc.org>; Thu, 30 Nov 2000 02:47:16 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA65534; Thu, 30 Nov 2000 11:54:58 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA14738; Thu, 30 Nov 2000 11:48:10 +0100
Message-ID: <3A26306D.CC0C8D44@bull.net>
Date: Thu, 30 Nov 2000 11:48:13 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <MMyers@verisign.com>
CC: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <2F3EC696EAEED311BB2D009027C3F4F401C5BAB7@vhqpostal.verisign.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA26765
Mike,
As mentioned below, once more time, you do not provide any TECHNICAL answer.
I am still awaiting TECHNICAL answers to my questions.
> Denis,
>
> I will try again with responses embedded below for full context.
> Mike
>
> > Michael,
> >
> > I pick up this message to tell you that:
> >
> > > Dave,
> > >
> > > > On Monday, November 20, 2000 8:58 AM you said in part:
> > > >
> > > > CRL-driven [OCSP] responders are a requirement in my
> > > > environment, and OCSP products which cannot be fed
> > > > by CRLs will not be purchased.
> > >
> > > When I said that "OCSP isn't and should't be tied to CRLs",
> > I was observing
> > > that CRLs are one means for a CA to store the data needed by an OCSP
> > > responder. Alternatives exist; these include direct
> > database lookup or an
> > > LDAP-based query of a directory. We must preserve that
> > flexibility. RFC
> > > 2560 enables use of CRLs in any variation. There's neither
> > intent nor
> > > proposal to remove that support.
> >
> > 1° I agree with your text. The implication is that any basic status
> > revocation response should be built using only information
> > that is present
> > in "fresh" CRLs. This may be self-evident, but it is better to say it.
>
> First you say, "I agree with your text" (which asserts that CRLs aren't
> required but rather their use is enabled), then you say that basic response
> should be built using ONLY [my emphasis] information present in fresh CRLs.
> These statements cancel each other out as far as I'm able to parse them.
> Please clarify.
Rather easy. OCSP server may use any information they wish (e.g. a private
access to a database of the non revoked certificates from the CA (if this
exists) or CRLs). Howveer, since the requester wants the same kind of
response whatever source of information is being used, only the common
denominator of that information should be used to produce the response. In
particular there should be no assumption that the OCSP server, * for a
revocation status query *, has access to more information than the one
contained in a CRL.
For other types of queries (i.e. other than revocation status queries), this
does not apply.
> > 2° I am still awaiting a response from you on my previous
> > E-mails. Since you
> > might not remember, here is now (for the third time), the
> > questions that I
> > raised:
>
> I'll try again below with full context included.
>
> >
> > ==============================================================
> > ==========
> >
> > E-mail from November, 15:
> >
> > Mike,
> >
> > A few, but important comments on this E-mail sent last week.
> >
> > > Russ, thanks for getting this debate kicked off. After all
> > the work various
> > > of us have put into this issue, I was beginning to think no
> > one cared.
> > >
> > > All, as to the debate:
> > >
> > > Let's hear from everybody before we make a decision.
> > > ----------------------------------------------------
> > > Thanks to all who have read the IDs and provided comments
> > (especially Denis
> > > Pinkas). But since active WG members have taken time out
> > of their busy
> > > schedules to improve the IDs, I think it only fair that
> > final judgement be
> > > witheld until those contributions are folded into a revised
> > version for our
> > > consideration in San Diego. At that time it might be more
> > appropriate to
> > > decide between the two.
> > >
> > > It's DPV vs. SCVP
> > > -----------------
> > > OCSP-X has expired; DPV and DPD replace that initial work.
> > The requirement
> > > we're all most concerned about is delegated path validation
> > (although
> > > delegated path discovery has it's use). So it really comes
> > down to DPV+DPD
> > > vs. SCVP since OCSP is already RFC 2560. DPV is little
> > more than an OID and
> > > a corresponding semantic; it simply puts more meat behind
> > 2560's notion of
> > > "good".
> >
>
> Denis said:
>
> > I disagree with this last statement. Extensions allows to request new
> > services. The request for each every new service may fail or
> > succeed. This
> > means that each extension will have to carry the result of
> > the request for
> > the new service. This also means that the current status will
> > only carry the
> > response to a *status revocation request*, but will not carry
> > any additional
> > meaning. "Good" is not the appropriate term to be used: "not
> > revoked" is the
> > right term and should be used instead, when we revised OCSP.
> >
>
> Response:
>
> On 11/17 under the subject "Re: DPV vs. SCVP", in response to your proposal
> to change "good" back to "not revoked" I responded in part as follows:
>
> "It's my sense that once the IETF makes a decision that leads to an RFC, we
> should be very cautious in recanting on those recommendations . . . . It's
> my opinion that we must think through a reset of the "good" and "unknown"
> status responses very carefully . . . . I look to the chairs for guidance
> to help me ensure that the IETF process is fully respected as we go forward
> . . . ."
I DID see this previous response from you. I present TECHNICAL arguments and
you reply, one more time, using PROCEDURAL arguments. I consider that this
is, once again, a non-response from you. I am still awaiting a TECHNICAL
answer to this question.
> If your definition of "response" means "the I-D hasn't been changed as I
> asked." that much is true for the reasons I cited above. However, and as
> I've said repeatedly, I remain open to strong consensus from the WG on your
> proposal or equivalently direction from the chairs.
>
> While I haven't conferred with my co-authors on this point, it would be
> useful to know if you would find acceptable an expansion of the CertStatus
> field of BasicOCSPResponse to include "not revoked" among the current
> "good", "revoked" and "unknown", with corresponding amendments to the
> related semantic text.
>
> > > DPD is only a bit more along these same lines of design.
> > >
> > > They're going to do it anyway.
> > > ------------------------------
> > > DPV and DPD are nothing more than proposed standard
> > extensions to the
> > > already existing extension hooks in 2560. Given the
> > availablility of those
> > > hooks, there's nothing to stop any environment from doing
> > precisely this, if
> > > only to establish a closed system-level solution. Given
> > that, it's better
> > > that we take responsible action to promote Internet
> > interoperability via a
> > > standard means of doing so in the event that such closed
> > environments may
> > > someday find it useful to interoperate.
> >
>
> Denis said:
>
> > The real advantage to add DPV and DPD to OCSP is to be able
> > to support both
> > a revocation status request and DPV or DPV+DPD in a single request. It
> > should however be noticed that a response to a status
> > revocation request is
> > not mandatory since the server may well return a "revocation
> > status unknown"
> > response, but still respond to a DPD (Delegated Path
> > Discovery) for the
> > certificate.
> >
> >
>
> Response:
>
> Again, on 11/17 under the subject "Re: DPV vs. SCVP", I responded in part as
> follows:
>
> "I had hoped that you considered my prior emails as responsive.
Your hopes failed. :-(
Once more time, you do not provide any TECHNICAL answer. I am still awaiting
a TECHNICAL answer to this question.
Regards,
Denis
> Some of
> your comments I didn't take to be actionable in the absence of a broader
> consensus. I'll take another look at them today to see if I missed
> something obvious."
>
> Would consider responsive my ad-hoc proposal above to consider expansion of
> the spectrum of CertStatus values in BasicOCSPResponse?
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA29948 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 21:10:49 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4T00101NSMD5@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 29 Nov 2000 21:12:22 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4T000GMNSMIX@ext-mail.valicert.com>; Wed, 29 Nov 2000 21:12:22 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <X7K0DLH7>; Wed, 29 Nov 2000 21:09:50 -0800
Content-return: allowed
Date: Wed, 29 Nov 2000 21:09:49 -0800
From: Frank Balluffi <frankb@valicert.com>
Subject: RE: OIDs as URIs
To: "'phil.griffin@asn-1.com'" <phil.griffin@asn-1.com>, ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E1366F0@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Phil,
So it sounds like pot://1-800-CALL-ROB?1.3.14.3.2.27 (where pot stands for
plain-old telephone) may be more useful than oid://1.3.14.3.2.27 :-)?
Frank
> -----Original Message-----
> From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com]
> Sent: Thursday, November 30, 2000 4:30 AM
> To: ietf-pkix@imc.org
> Subject: Re: OIDs as URIs
>
>
> Turns out that even if you're an old geezer that
> knows oiw is open implementors workshop, you still
> wouldn't have a clue to contact Rob. And if you did
> he'd tell you as former registrar that the registry
> has long been closed down.
>
> The numbers are all that a program needs to switch
> off of. Either the application knows what the number
> means or it doesn't. Very simple.
>
> Phil
>
>
>
> Karl Scheibelhofer wrote:
> >
> > > -----Original Message-----
> > > From: Rich Salz [mailto:rsalz@caveosystems.com]
> > > Sent: Wednesday, November 29, 2000 12:52 PM
> > > To: Karl Scheibelhofer
> > > Cc: ietf-pkix@imc.org
> > > Subject: Re: OIDs as URIs
> > >
> > >
> > > > it should at least be possible to use a kind of
> NameAndNumberForm.
> > >
> > > Why? Under what circumstances is "enterprise-mib" better
> than "2"?
> > > We already know that names will hurt machine processing,
> and humans can
> > > clearly read numbers. What is the point of having the
> name? Who will
> > > be helped, and what will they do with it?
> >
> > one main reason for expressing OIDs as URIs is that we want
> to use the
> > within XML documents. normally one can read a XML document
> with a text
> > editor and get a good idea of what it is all about.
> > if you use pure number OIDs in it, you have normally no
> idea, what that
> > means.
> > try to guess waht 1.3.14.3.2.27 means (without browsing into some
> > web-directory).
> > then try to read {iso(1) identified-organization(3) oiw(14)
> secsig(3)
> > algorithms(2) sha1(27)}.
> > i think we do not need discuss, what is easier to read for humans.
> >
> > regards
> >
> > Karl Scheibelhofer
> >
> > --
> >
> > Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
> > Institute for Applied Information Processing and
> Communications (IAIK)
> > at Technical University of Graz, Austria, http://www.iaik.at
> > Phone: (+43) (316) 873-5540
>
> --
> Phil
> ----
> Phillip H. Griffin Griffin Consulting
> http://asn-1.com Secure ASN.1 Design & Implementation
> +1-919-832-7008 1625 Glenwood Avenue, Five Points
> +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA
> ------------------------------------------------------------
>
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA29584 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 21:01:07 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4T00101NCAC6@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 29 Nov 2000 21:02:34 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4T000F2NCAIX@ext-mail.valicert.com>; Wed, 29 Nov 2000 21:02:34 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <X7K0DLHG>; Wed, 29 Nov 2000 21:00:02 -0800
Content-return: allowed
Date: Wed, 29 Nov 2000 21:00:01 -0800
From: Frank Balluffi <frankb@valicert.com>
Subject: RE: OIDs as URIs
To: Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at>
Cc: ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E3CBA3B@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Karl Scheibelhofer said:
> one main reason for expressing OIDs as URIs is that we want to use the
> within XML documents.
Then why not just define one or more XML elements. One possibility would be
to define an element that contains one number form for which its name may be
specified as an attribute:
<oid>
<oid-number name="iso">1</oid-number>
<oid-number name="member-body">2</oid-number>
<oid-number name="US">840</oid-number>
<oid-number name="rsadsi">113549</oid-number>
<oid-number name="pkcs">1</oid-number>
<oid-number name="pkcs-1">1</oid-number>
<oid-number name="rsaEncryption">1</oid-number>
</oid>
[I think I got that right.]
I am still confused as to the purpose of a Uniform Resource Identifier (URI)
for an object identifier. It seems to me that a URI identifies a way to use
a resource whereas an object identifier just identifies something (e.g., an
algorithm).
For example, suppose I have a URI for the RSA encryption algorithm, what can
I do with it?
Frank
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA27668 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 20:07:38 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA12690; Thu, 30 Nov 2000 14:07:07 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <XZFQ9R1K>; Thu, 30 Nov 2000 14:57:42 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCADE0C98@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Aram Perez <aram@pacbell.net>, PKIX <ietf-pkix@imc.org>
Subject: RE: OIDs as URIs
Date: Thu, 30 Nov 2000 14:57:40 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
>
> [snip]
> > A better deal for XML encoding would be to denote OIDs as
> numbers only (so
> > that a machine is happy), and to have an attribute with a
> human-readable
> > context - for example, friendlyName="dsaWithSha1encryption".
> >
> > <OID id="urn:oid:1.3.14.2.2.27"
> friendlyName="dsaWithSha1Encryption"/>
>
> While I like your suggestion very much, I would take it one
> step further as
> follows:
>
> <OID id="1.3.14.2.2.27" friendlyName="dsaWithSha1Encryption"/>
>
> I don't see what the "urn:oid:" adds.
>
I don't see either, frankly. The OID element will be always defined within a
particular namespace. Within that namespace (probably the only and single
one, referenced by every XML shema requiring using of oids), the meaning of
"id" attribute is unambiguous enough. So that we don't need to put any extra
qualifiers in front of the numbers, explaining what the numbers are.
Received: from mail2.cpip.net.cn ([210.73.64.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA26371 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 19:41:31 -0800 (PST)
Date: Wed, 29 Nov 2000 19:41:31 -0800 (PST)
From: V@tzw.de
Message-Id: <200011300341.TAA26371@ns.secondary.com>
Received: from h809 ([63.30.194.82]) by mail2.cpip.net.cn (Netscape Messaging Server 3.01) with SMTP id AAO17112; Thu, 30 Nov 2000 11:47:04 +0800
To: V@tzw.de
Subject: Lady V: The Pleasure Pill for Women!
LADY V: The Pleasure Pill for Women!
Men Have Their Viagra®! Finally, A Pill for Women!
It's Here! The Revolutionary Woman's Sexual Sensation is Now
Available.
Researchers are calling Lady V the greatest breakthrough
for women since the Birth Control Pill. And you don't even need
a prescription to get it!
Welcome to the New Sexual Revolution!
It's no secret that men have been having the time of their
lives since the wonder pill Viagra® was made available. But,
women were left out in the cold with no pill... nothing!
Well now thanks to an all-star team of medical researchers
who have been working around the clock, those days are finally
over. The perfect female "pleasure pill" has been created and
you don't even need a prescription. You can now get it from
Lion Sciences!
Lady V is the world's first pleasure pill scientifically
designed for women. Lady V is an all-natural proprietary
herbal blend of prosexual nutrients from around the world
synergistically blended to naturally stimulate neurotransmitter
endorphin signals. This magical combination increases targeted
blood flow, unleashes natural stimulator for maximum stimulation,
triggering pleasure responses quickly. Lady V is safe, natural
and doctor-recommended.
Since its introduction Lady V has been taking the world by storm!
>From Malibu to Miami women are enjoying the most intense pleasure
of their lives!
• 100% Natural
• Safe
• The Highest Quality Pharmaceutical Pure Nutraceuticals
• Guaranteed Potency
• Certified Purity
Lady V is Sweeping the Nation!
Women are going crazy over Lady V. Suddenly couples are falling
in love all over again. The passion and pleasure that women are
reporting is off the charts! Lady V has an incredible 88% success
rate. Best of all, while Viagra costs $10 a pill, Lady V costs
less than $1 a pill! It's not just a man's world anymore!
Just look at what a few women have to say:
"I thought my love life was good before, but now it is out of
this world! Lady V is remarkable." — Mary J., Interior Designer
"I haven't smiled like this in a long time. My husband and I
feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer
"Imagine what it would feel like to have incredible passion
and pleasure anytime you want." — Jennifer C., Film Editor
"Suddenly my husband and I are spending more time in the bedroom
instead of the TV room." — Angie R., Realtor
Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid,
Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract,
Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana,
and L-Taurine.
Each bottle of Lady V contains 30 tablets.
Take three capsules one hour before romantic activity
as a dietary supplement.
Risk Free: Double Your Money Back Guarantee
If Lady V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked!
Order Now: Safe, Fast, Secure, Private
Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.
Payment Methods
You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail.
Each bottle of Lady V contains 30 tablets.
Step 1: Place a check by your desired quanity.
______ 1 Bottle of Lady V $24
______ 2 Bottles of Lady V $44
______ 3 Bottles of Lady V $59
Please add $6 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]
International Orders
Please add $18 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ]
We cannot accept foreign checks.
International money orders or credit cards only.
Step 2: Place a check by your desired payment method
and complete fields if necessary.
_____Check or CHECK-BY-FAX [details below]
_____Money Order
_____American Express
Account Number__________________ Exp____/____
_____Visa
Account Number__________________ Exp____/____
_____MasterCard
Account Number__________________ Exp____/____
Please make your check or money order payable to
"Lion Sciences National".
Step 3: Please complete and print the following fields clearly.
Name ___________________________________________________
Address _________________________________________________
City ____________________________________________________
State ___________________________________________________
Zip _____________________________________________________
E-mail __________________________________________________
Signature _________________________________________________
[ required for check and credit card orders]
Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all.
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.
Or, print & mail to: LSN
273 S. State Rd. 7, #193
Margate, FL 33068-5727
______________________________________________________
*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !
TAPE CHECK BELOW
_____________________________________________________________
This is a one time mailing: Removal is automatic and no further
contact is necessary. Please Note: Lady V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Lady V helps provide herbal and nutritional support
for female sexual performance. The FDA has not evaluated these
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs
department; enclose a self addressed stamped envelope for this and any
requested contact information.
Thank You.
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25971 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 19:36:01 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p050104a5b64b7b50506e@[165.227.249.17]>
In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F401C5BC07@vhqpostal.verisign.com>
References: <2F3EC696EAEED311BB2D009027C3F4F401C5BC07@vhqpostal.verisign.com>
Date: Wed, 29 Nov 2000 19:37:33 -0800
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: A new XMLPKI WG?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 7:23 PM -0800 11/29/00, Michael Myers wrote:
>This feast may move but the song remains the same. I for one see no reason
>for a new WG re: XML+PKI. It's just going to be the same people, the same
>voices, etc. Would it not more effective to simply amend our existing
>charter and motor on? Just a thought. In any event, $10US (ten dollars US)
>out of my pocket to the first person who correctly identifies onlist the
>references implied in the first sentence.
Hey! Something that Mike and I agree on. :-) If the work is kept
within this WG, it will force the proposers to explain the value add
for XML for the certificate and CRL and OCSP replacements. I, for
one, would be interested in hearing those.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25541 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 19:25:20 -0800 (PST)
Received: from asn-1.com (user-2ivf0mk.dialup.mindspring.com [165.247.130.212]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA31347 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 22:26:52 -0500 (EST)
Message-ID: <3A261E2B.3559280F@asn-1.com>
Date: Thu, 30 Nov 2000 04:30:19 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: OIDs as URIs
References: <NDBBJJNFOMNNKFDPLCDJEEHHCEAA.Karl.Scheibelhofer@iaik.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Turns out that even if you're an old geezer that
knows oiw is open implementors workshop, you still
wouldn't have a clue to contact Rob. And if you did
he'd tell you as former registrar that the registry
has long been closed down.
The numbers are all that a program needs to switch
off of. Either the application knows what the number
means or it doesn't. Very simple.
Phil
Karl Scheibelhofer wrote:
>
> > -----Original Message-----
> > From: Rich Salz [mailto:rsalz@caveosystems.com]
> > Sent: Wednesday, November 29, 2000 12:52 PM
> > To: Karl Scheibelhofer
> > Cc: ietf-pkix@imc.org
> > Subject: Re: OIDs as URIs
> >
> >
> > > it should at least be possible to use a kind of NameAndNumberForm.
> >
> > Why? Under what circumstances is "enterprise-mib" better than "2"?
> > We already know that names will hurt machine processing, and humans can
> > clearly read numbers. What is the point of having the name? Who will
> > be helped, and what will they do with it?
>
> one main reason for expressing OIDs as URIs is that we want to use the
> within XML documents. normally one can read a XML document with a text
> editor and get a good idea of what it is all about.
> if you use pure number OIDs in it, you have normally no idea, what that
> means.
> try to guess waht 1.3.14.3.2.27 means (without browsing into some
> web-directory).
> then try to read {iso(1) identified-organization(3) oiw(14) secsig(3)
> algorithms(2) sha1(27)}.
> i think we do not need discuss, what is easier to read for humans.
>
> regards
>
> Karl Scheibelhofer
>
> --
>
> Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
> Institute for Applied Information Processing and Communications (IAIK)
> at Technical University of Graz, Austria, http://www.iaik.at
> Phone: (+43) (316) 873-5540
--
Phil
----
Phillip H. Griffin Griffin Consulting
http://asn-1.com Secure ASN.1 Design & Implementation
+1-919-832-7008 1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25142 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 19:21:59 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id TAA11589; Wed, 29 Nov 2000 19:25:03 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNF2JW3J>; Wed, 29 Nov 2000 19:23:27 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BC08@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Steve Hanna <steve.hanna@sun.com>, ietf-pkix@imc.org
Subject: RE: Comments on draft-ietf-pkix-new-part1-03
Date: Wed, 29 Nov 2000 19:23:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Steve,
You asked on Wednesday, November 29, 2000 12:20 PM
> I don't have a strong opinion about whether unique
> identifiers are useful and whether they are actually
> used. Does anybody believe that they are?
FWIW, I don't. I consider them a "Panda's thumb"--present by evolution but
useless in practice.
Mike
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25067 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 19:21:47 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id TAA15157 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 19:19:19 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNFT3VF5>; Wed, 29 Nov 2000 19:23:21 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BC07@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: PKIX-List <ietf-pkix@imc.org>
Subject: A new XMLPKI WG?
Date: Wed, 29 Nov 2000 19:23:18 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
All,
This feast may move but the song remains the same. I for one see no reason
for a new WG re: XML+PKI. It's just going to be the same people, the same
voices, etc. Would it not more effective to simply amend our existing
charter and motor on? Just a thought. In any event, $10US (ten dollars US)
out of my pocket to the first person who correctly identifies onlist the
references implied in the first sentence.
Mike
Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24688 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 19:12:01 -0800 (PST)
Received: from [192.168.1.35] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G4T00MTJHF9W0@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Wed, 29 Nov 2000 18:54:46 -0800 (PST)
Date: Wed, 29 Nov 2000 18:55:51 -0800
From: Aram Perez <aram@pacbell.net>
Subject: Re: OIDs as URIs
In-reply-to: <D44EACB40164D311BEF00090274EDCCADE0BD5@sydneymail1.jp.zergo.com.au>
To: PKIX <ietf-pkix@imc.org>
Message-id: <B64B01B6.2974%aram@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022
Michael Zolotarev wrote:
[snip]
> A better deal for XML encoding would be to denote OIDs as numbers only (so
> that a machine is happy), and to have an attribute with a human-readable
> context - for example, friendlyName="dsaWithSha1encryption".
>
> <OID id="urn:oid:1.3.14.2.2.27" friendlyName="dsaWithSha1Encryption"/>
While I like your suggestion very much, I would take it one step further as
follows:
<OID id="1.3.14.2.2.27" friendlyName="dsaWithSha1Encryption"/>
I don't see what the "urn:oid:" adds.
Feliz Navidad,
Aram Perez
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA23557 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 18:27:23 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id MAA11632; Thu, 30 Nov 2000 12:36:22 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <XZFQ9RBL>; Thu, 30 Nov 2000 13:26:56 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCADE0BD5@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at>, Rich Salz <rsalz@caveosystems.com>
Cc: ietf-pkix@imc.org
Subject: RE: OIDs as URIs
Date: Thu, 30 Nov 2000 13:26:53 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
I dare to say that for a human eye {iso(1) identified-organization(3)
oiw(14) secsig(3) algorithms(2) sha1(27)} is too much as well. And a human
doesn't make sense of it - even if the length of it pleases.
A better deal for XML encoding would be to denote OIDs as numbers only (so
that a machine is happy), and to have an attribute with a human-readable
context - for example, friendlyName="dsaWithSha1encryption".
<OID id="urn:oid:1.3.14.2.2.27" friendlyName="dsaWithSha1Encryption"/>
Michael
> -----Original Message-----
> From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at]
> Sent: Wednesday, 29 November 2000 22:09
> To: Rich Salz
> Cc: ietf-pkix@imc.org
> Subject: RE: OIDs as URIs
>
>
> > -----Original Message-----
> > From: Rich Salz [mailto:rsalz@caveosystems.com]
> > Sent: Wednesday, November 29, 2000 12:52 PM
> > To: Karl Scheibelhofer
> > Cc: ietf-pkix@imc.org
> > Subject: Re: OIDs as URIs
> >
> >
> > > it should at least be possible to use a kind of NameAndNumberForm.
> >
> > Why? Under what circumstances is "enterprise-mib" better than "2"?
> > We already know that names will hurt machine processing,
> and humans can
> > clearly read numbers. What is the point of having the
> name? Who will
> > be helped, and what will they do with it?
>
> one main reason for expressing OIDs as URIs is that we want to use the
> within XML documents. normally one can read a XML document with a text
> editor and get a good idea of what it is all about.
> if you use pure number OIDs in it, you have normally no idea,
> what that
> means.
> try to guess waht 1.3.14.3.2.27 means (without browsing into some
> web-directory).
> then try to read {iso(1) identified-organization(3) oiw(14) secsig(3)
> algorithms(2) sha1(27)}.
> i think we do not need discuss, what is easier to read for humans.
>
> regards
>
> Karl Scheibelhofer
>
> --
>
> Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
> Institute for Applied Information Processing and Communications (IAIK)
> at Technical University of Graz, Austria, http://www.iaik.at
> Phone: (+43) (316) 873-5540
>
Received: from smtp02.infoave.net (smtp02.infoave.net [165.166.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09599 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 12:31:17 -0800 (PST)
Received: from linus.corecom.com ([64.53.5.179]) by SMTP00.InfoAve.Net (PMDF V5.2-33 #45322) with ESMTP id <01JX48HWF98O9BWRVT@SMTP00.InfoAve.Net> for ietf-pkix@imc.org; Wed, 29 Nov 2000 15:32:17 EDT
Date: Wed, 29 Nov 2000 15:26:23 -0500
From: Dave Piscitello <dave@corecom.com>
Subject: TISC 2001 Call for Papers, Abstracts
X-Sender: dave@corecom.com@mail2.netreach.net
To: ietf-pkix@imc.org
Message-id: <4.3.2.7.2.20001129152534.00c20430@mail2.netreach.net>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Content-type: text/plain; charset="us-ascii"; format=flowed
The Fifth Internet Security Conference will be held June 4-8,
2001 at the Century Plaza Hotel and Tower, 2025 Avenue of the
Stars, Century City Los Angeles, CA 90067-4696. TISC is an
educational forum for security professionals and practitioners.
The TISC Security Symposium is an opportunity for individuals
to share their expertise and practical experience with others
involved in the design, implementation and deployment of
networked security systems.
We cordially invite you to submit an abstract for an original
paper. Accepted papers will be presented at the conference.
We also invite you to submit a session abstract for
consideration, or if you prefer, to present a topic as a
panel member. We encourage you to submit abstracts and topics
by December 8. Further information can be found at
http://tisc.corecom.com. Or send your proposal to me
at mailto:dave@corecom.com.
We look forward to your participation. Thank you.
Warm Regards,
Dave Piscitello
On behalf of the TISC Advisory Board
David M. Piscitello
Core Competence, Inc. (http://www.corecom.com) and
The Internet Security Conference (http://tisc.corecom.com)
~~ The Internet has security problems. We have answers. ~~
3 Myrtle Bank Lane dave@corecom.com
Hilton Head, SC 29926 1.843.683-9988
PGP Fingerprint: 070A 9F01 C35C 4D41 A460 EF2C 2992 2F12 11D2 02DC
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08699 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 12:20:32 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05016 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 12:22:04 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA23658 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 15:22:01 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id PAA19938 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 15:22:00 -0500 (EST)
Message-ID: <3A2564D9.EF8B5107@sun.com>
Date: Wed, 29 Nov 2000 15:19:37 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Comments on draft-ietf-pkix-new-part1-03
References: <3A252215.18208B12@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
As I said in my earlier note, I'm very pleased with this document and I'd like
to see it go to Working Group Last Call soon. However, I do have a few
comments:
1) The first paragraph of section 6 (Certification Path Validation) says
the relying party can constrain the binding by specifying "initial state
variables". But this terminology is not consistent with section 6.1.1,
which refers to the relying party specifying "seven inputs", which are
used during the initialization phase to establish "eleven state
variables".
I expect that phrase in section 6 really means that the relying party can
constrain the binding by specifying those seven inputs. If so, then that
paragraph should say "inputs" instead of "initial state variables". If
not, then I would like to know what that phrase means.
2) In new-part1-03, the issuer unique identifier was removed from the trust
anchor information and from most parts of the validation algorithm.
I assume that this was done because section 4.1.2.8 says "CAs conforming
to this profile SHOULD NOT generate certificates with unique identifiers".
I have heard on at least one occasion that "nobody uses unique
identifiers". Certainly, I have never seen them used.
However, section 4.1.2.8 also says "Applications conforming to this
profile SHOULD be capable of parsing unique identifiers and making
comparisons." If we retain this recommendation, the validation algorithm
should include a step where unique identifiers are compared.
In new-part1-03, the only place where unique identifiers are mentioned in
the validation algorithm is step (a) (5) of section 6.1.3, which says:
(5) The certificate issuer unique identifier is the
working_issuer_UID, meaning:
(i) working_issuer_UID is non-null and matches the value in
the issuerUID field, or
(ii) working_issuer_UID is null and the issuerUID field is
not present.
But working_issuer_UID is no longer set anywhere.
If we really feel that unique identifiers are not useful and not used, we
could simplify the validation algorithm by saying that any certificate
containing an issuer unique identifier or subject unique identifier should
be rejected. And we should change section 4.1.2.8 to reflect this.
If, on the other hand, we want the validation algorithm to include support
for comparing unique identifiers, we should describe in section 6.1 how
working_issuer_UID is initialized and updated.
I don't have a strong opinion about whether unique identifiers are useful
and whether they are actually used. Does anybody believe that they are?
-Steve
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06278 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 11:46:08 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA16513 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 11:49:16 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNF2JQXK>; Wed, 29 Nov 2000 11:47:36 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BBD6@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: ietf-pkix@imc.org
Subject: RE: OCSP identifiers: current tally
Date: Wed, 29 Nov 2000 11:47:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
All,
Current tally re: amending RFC 2560's certID syntax:
On Tuesday, November 28, 2000 8:14 PM, Phillip H. Griffin wrote:
> I . . . definitely support your efforts to amend the certID
> syntax.
On Tuesday, November 28, 2000 3:52 PM, Carlin Covey wrote:
> Since we seem to be taking a straw poll here, let me cast my
> (uncertified) vote in favor of OCSPv2's proposal to amend
> RFC 2560's certID syntax.
In addition, Denis requested to be moved to opposed.
Denis, I must ask again, could you please clarify your position? It seems
to me that we can either count you in favor and I'll pick up on Phil's offer
and ask him if he'd be willing to take a closer look at the comparative
value of both expressions at the ASN.1 level, or we can count you as opposed
in which case there's no need to seek Phil's guidance.
Anyway, we currently have as a delta to the previous tally:
10 in favor (minus Pinkas, plus Covey, plus Griffin)
3 opposed (plus Pinkas)
Mike
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01837 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 10:36:40 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA05657 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 10:39:47 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNF2JMT8>; Wed, 29 Nov 2000 10:38:11 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154C70C@vhqpostal.verisign.com>
From: Philip Hallam-Baker <pbaker@verisign.com>
To: ietf-pkix@imc.org
Subject: XML Key Management Services
Date: Wed, 29 Nov 2000 10:38:07 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0003_01C05A09.D584A760"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
This is a multi-part message in MIME format.
------=_NextPart_000_0003_01C05A09.D584A760
Content-Type: multipart/mixed;
boundary="----=_NextPart_001_0004_01C05A09.D584A760"
------=_NextPart_001_0004_01C05A09.D584A760
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Following up on the discussion on XML based PKI, those interested can
read about the proposal we announced this morning together with
webMethods and Microsoft.
http://www.verisign.com/developer/xml/index.html
The intention is to develop the specification further as an open
standards in a standards body that is generally considered a good fit.
I would like to request that the PKIX chairs allow a slot on the agenda
to present the initiative and how we see it as complementing
PKIX/SPKI/PGP rather than being a direct competitor.
Phill
Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
------=_NextPart_001_0004_01C05A09.D584A760
Content-Type: text/x-vcard;
name="Philip Hallam-Baker.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="Philip Hallam-Baker.vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Philip
FN:Philip Hallam-Baker
ORG:VeriSign, Inc.;Sales
TEL;WORK;VOICE:781-245-6996x227
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;401 Edgewater =
Place=3D0D=3D0ASuite 280;Wakefield;MA;01880-6206;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:401 Edgewater =
Place=3D0D=3D0ASuite 280=3D0D=3D0AWakefield, MA 01880-6206=3D0D=3D0AUSA
KEY;X509;ENCODING=3DBASE64:
=
MIIEFDCCA32gAwIBAgIQAxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUG
=
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
=
STBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlz
=
aWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95
=
ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAxMjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJ
=
U0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJlY2lwaWVudHMxNTAzBgNVBAMTLHBiYWtl
=
ciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24sIEluYy4pMIGfMA0GCSqGSIb3DQEB
=
AQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf/wsvxS//4Nt8rFgr2KdvQETK
=
aQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfqPKAdxu/Fvb4n3Y0RItW9
=
zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IBdDCCAXAwCQYDVR0T
=
BAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlzaWduLmNvbS9W
=
ZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMCBaAwHgYD
=
VR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF
=
AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr
=
BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y
=
cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB
=
BAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOB
=
gQAaUApBXCjcmPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaY
=
CRgv69qKTVoANmsMF/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgo
NvO0fcknSlNOWxqHvbaH9RYvhMghkg=3D=3D
EMAIL;PREF;INTERNET:pbaker@verisign.com
REV:20000308T174211Z
END:VCARD
------=_NextPart_001_0004_01C05A09.D584A760--
------=_NextPart_000_0003_01C05A09.D584A760
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ
AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx
MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s
IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf
/wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq
PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB
dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz
aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC
BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB
hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr
BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g
YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA
MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc
mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM
F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH
9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy
bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy
aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB
jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDExMjkxODM5NDRa
MCMGCSqGSIb3DQEJBDEWBBQhoqGLdh1nCKge6vTZkELIYyNhOzBYBgkqhkiG9w0BCQ8xSzBJMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl
MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN
BgkqhkiG9w0BAQEFAASBgBC+FJ5a98zA9edS41zxvqDFKxXfw5byVf+fReeAae5q4+uzzTZNGoNG
cX8PixvUE8kdOE4sqoPgFxBJJ8wmOrqLhCBPy+jGJuT92rv60Yb8s3t4CBkvKLHEXpfUQ5rSop+k
n81IOSIerA0lnz+a2adS5OAQi5P8/3rPSs7nI7WLAAAAAAAA
------=_NextPart_000_0003_01C05A09.D584A760--
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01443 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 10:32:46 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA05267; Wed, 29 Nov 2000 10:35:50 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNF2JMQC>; Wed, 29 Nov 2000 10:34:14 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BBB9@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Stephen Kent <kent@bbn.com>
Cc: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Wed, 29 Nov 2000 10:34:05 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Steve,
It's our objective to amend RFC 2560's certID syntax while preserving all
that RFC 2560 has established. I have always presumed this would lead to a
new RFC number. We're doing so in order to address known needs to expand
the means by which certificates can be identified in the OCSP bit stream.
Alternatively, we could editorially amend RFC 2560 and so move it from
proposed to draft. As briefed in Pittsburg however, many of us believe it's
best to take the former course of action.
To that end, the v2 certID syntax is amendend in a fashion that enables v1
interoperability. Further, both OCSPv2 servers and clients are required to
be capable of backwards interoperablity with their v1 peers. There's no
need to deprecate the use of v1 if the original certID syntax satisfies
local requirements. It's only when environments wish to, say, use CMS's
IssuerandSerialNumber vs. original certID that use of the v2 version number
in the bit stream is required. Other than that, it's precisely the same
protocol, simply amended to enable its use in other contexts.
Hope that clarifies things.
Mike
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Tuesday, November 28, 2000 3:56 PM
> To: Michael Myers
> Cc: ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
> . . . .
>
> I think there is ample support and technical rationale for this
> change, but it's significant enough to reset advancement for the OCSP
> document, i.e., v2 is a new standard. You'll have to decide if it
> supercedes v1, etc. I'm awfully far behind on my e-mail. so maybe
> I've missed this part of the debate, but what are the plans re OCSP
> v1, i.e., since we all loathe parallel, mostly equivalent versions of
> standards, is the proposal to replace v1 with v2, and denigrate the
> use of v1?
>
> Just asking ...
>
> Steve
>
Received: from slack.lne.com (IDENT:root@[209.157.136.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23610 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 08:12:20 -0800 (PST)
Received: (from ericm@localhost) by slack.lne.com (8.11.0/8.11.0) id eATGCvu19220; Wed, 29 Nov 2000 08:12:57 -0800
Date: Wed, 29 Nov 2000 08:12:57 -0800
From: Eric Murray <ericm@lne.com>
To: Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at>
Cc: Rich Salz <rsalz@caveosystems.com>, ietf-pkix@imc.org
Subject: Re: OIDs as URIs
Message-ID: <20001129081257.M23326@slack.lne.com>
References: <3A24EDD5.8877AC29@caveosystems.com> <NDBBJJNFOMNNKFDPLCDJEEHHCEAA.Karl.Scheibelhofer@iaik.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.2i
In-Reply-To: <NDBBJJNFOMNNKFDPLCDJEEHHCEAA.Karl.Scheibelhofer@iaik.at>; from Karl.Scheibelhofer@iaik.at on Wed, Nov 29, 2000 at 01:09:12PM +0100
On Wed, Nov 29, 2000 at 01:09:12PM +0100, Karl Scheibelhofer wrote:
> > -----Original Message-----
> > From: Rich Salz [mailto:rsalz@caveosystems.com]
> > Sent: Wednesday, November 29, 2000 12:52 PM
> > To: Karl Scheibelhofer
> > Cc: ietf-pkix@imc.org
> > Subject: Re: OIDs as URIs
> >
> >
> > > it should at least be possible to use a kind of NameAndNumberForm.
> >
> > Why? Under what circumstances is "enterprise-mib" better than "2"?
> > We already know that names will hurt machine processing, and humans can
> > clearly read numbers. What is the point of having the name? Who will
> > be helped, and what will they do with it?
>
> one main reason for expressing OIDs as URIs is that we want to use the
> within XML documents. normally one can read a XML document with a text
> editor and get a good idea of what it is all about.
Given what's happened to HTML in the last 5 years, don't expect that
to last long unless a concerted effort is made in all XML standards
groups to maintain human readability.
> if you use pure number OIDs in it, you have normally no idea, what that
> means.
> try to guess waht 1.3.14.3.2.27 means (without browsing into some
> web-directory).
> then try to read {iso(1) identified-organization(3) oiw(14) secsig(3)
> algorithms(2) sha1(27)}.
> i think we do not need discuss, what is easier to read for humans.
99% of humans won't know what either format means. Of the remaining
1%, 95% will only understand the string "sha1" and none of the rest.
Most crypto programmers simply get an OID from something else that's
similar (which is why OIDs from obsolete documents keep appearing-
that's what was in the library when the programmer went looking for an
appropriate OID). Expressing OIDs as URIs instead of numbers won't
fix this or make any more people understand them, it'll just take up
more space.
Also, what happens when you're parsing a string which has
correct numbers but incorrect names? I.e. your example
iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) sha1(27)
being incorrect:
iso(1) identified-organization(3) junk(14) secsig(3) algorithms(2) sha1(27)
The numbers in the string are correct, but not the names. Which
is used when you're parsing the OID? Both? Just the names? Just the
numbers?
--
Eric Murray Consulting Security Architect SecureDesign LLC
http://www.securedesignllc.com PGP keyid:E03F65E5
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18365 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 07:35:39 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23331 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 07:37:10 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA05976 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 10:37:09 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA25972 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 10:37:08 -0500 (EST)
Message-ID: <3A252215.18208B12@sun.com>
Date: Wed, 29 Nov 2000 10:34:45 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Changes in draft-ietf-pkix-new-part1-03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Here is a list of potentially significant changes between
draft-ietf-pkix-new-part1-02.txt and draft-ietf-pkix-new-part1-03.txt.
A simple diff will not suffice to find these changes because
hyphenation was turned off between these versions (probably to avoid
confusion and/or ambiguities). This caused many paragraphs to change
without any truly significant differences. I have edited the output of
diff to remove insignificant changes (such as typographical
corrections) and add comments about what each change means (in my
view).
I hope that this will be helpful for others who are closely tracking the
changes to this document.
To summarize, new-part1-03 includes the following changes:
1) Added recommendation that pseudonym attribute type be supported.
2) Support for inhibit any-policy extension now required instead of
recommended.
3) Removed recommendation against the subject directory attributes
extension.
4) Added a new section describing the subject information access extension.
5) Clarified that the relying party can supply constraints to the validation
algorithm via "initial state variables". Not quite clear what those are.
6) Removed the validity period of the public key from the set of inputs
required by the algorithm, since it was never used in the algorithm.
7) Clarified that features described as optional in early sections
may be omitted from the validation algorithm.
8) Removed the issuer unique identifier from the trust anchor information.
It still appears one place in the algorithm, but clearly the intent was
to remove it.
9) Added new behavior in policy processing to generate a child node of depth
i that has a valid_policy of ID-P if certificate i contains a policy
mapping extension with an issuerDomainPolicy ID-P and no node of depth i
in the valid_policy_tree has a valid_policy of ID-P but there is a node
of depth i with a valid_policy of any-policy.
10) Recommended that if you want to have different parameters for different
trust you should supply different inputs to the path validation
procedure. Old recommendation was to place limitations in the self-signed
certificates used as the trust anchors. But that isn't a great idea and
constraints in the trust anchors are not processed anyway (according to
the algorithm).
11) Added several minor clarifications relating to the CPS Pointer policy
qualifier, policy mapping, email addresses, extended key usage, the OCSP
AuthorityInformationAccess access descriptor, the most-trusted CA, and
long serial numbers.
I am quite pleased with these changes. I will send a separate email with
specific comments on this draft, but overall I think that it's in very good
shape and I would support moving it to WG Last Call soon. Minor issues and
typos can be resolved during the WG Last Call.
Completing work on this draft and moving it promptly to Proposed Standard
status will benefit other IETF working groups, whose documents depend on RFC
2459 and therefore cannot progress to Draft Standard status until this
document does so. Rapid progress on this draft will also benefit the PKI and
PKIX communities as a whole, since it will provide a stable standard on which
products can be based.
-Steve
------
My comments begin with a #. Lines from the -02 draft begin with a <.
Lines from the -03 draft begin with a >.
# In section 4.1.2.2 (Serial number),
# Added a comment emphasizing the requirements for serialNumbers. Similar
# text already appeared in Appendix B (and still does), but this
# location is much more prominent.
< certificate).
---
> certificate). CAs MUST force the serialNumber to be a non-negative
> integer.
>
> Given the uniqueness requirements above serial numbers can be
> expected to contain long integers. Certificate users MUST be able to
> handle serialNumber values up to 20 octets. Conformant CAs MUST NOT
> use serialNumber values longer than 20 octets.
>
> Note: Non-conforming CAs may issue certificates with serial numbers
> that are negative, or zero. Certificate users SHOULD be prepared to
> handle such certificates.
# In section 4.1.2.4 (Issuer),
# Added recommendation that pseudonym attribute type be supported.
< * initials, and
---
> * initials,
> * pseudonym, and
# In section 4.2 (Standard Certificate Extensions)
# inhibit any-policy now required instead of recommended
1527,1528c1540,1542
< (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and
< extended key usage (see sec. 4.2.1.13).
---
> (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), extended
> key usage (see sec. 4.2.1.13), and inhibit any-policy (see sec.
> 4.2.1.15).
# A bit later in the same section, more of the same change
< and inhibit any-policy (see sec. 4.2.1.15) extensions.
---
> and policy mapping (see sec. 4.2.1.6) extensions.
# In section 4.2.1.5 (Certificate Policies),
# Clarified handling for the CPS Pointer policy qualifier.
< The CPS Pointer qualifier contains a pointer to a Certification Prac-
< tice Statement (CPS) published by the CA. The pointer is in the form
< of a URI.
---
> The CPS Pointer qualifier contains a pointer to a Certification
> Practice Statement (CPS) published by the CA. The pointer is in the
> form of a URI. Processing requirements for this qualifier are a
> local matter. No action is mandated by this specification regardless
> of the criticality value asserted for the extension.
# In section 4.2.1.6 (Policy Mappings),
# Clarified that each policy included in the issuerDomainPolicy
# component of a policy mapping should be included in the certificate
# policies extension of the certificate that contains the policy
# mapping. Otherwise, what's the point in mapping to it?
< Policies should not be mapped either to or from the special value
< anyPolicy. (see 4.2.1.5 certificate policies).
---
> Each issuerDomainPolicy named in the the policy mapping extension
> should also be asserted in a certificate policies extension in the
> same certificate. Policies should not be mapped either to or from
> the special value anyPolicy. (See 4.2.1.5 certificate policies).
# In section 4.2.1.7 (Subject Alternative Name),
# Clarified that the use of the DNS representation for Internet mail
# addresses is prohibited.
< instead of wpolk@nist.gov) is not permitted; such identities are to
---
> instead of wpolk@nist.gov) MUST NOT be used; such identities are to
# In section 4.2.1.9 (Subject Directory Attributes),
# Removed recommendation against the subject directory attributes
# extension.
< The subject directory attributes extension is not recommended as an
< essential part of this profile, but it may be used in local environ-
< ments. This extension MUST be non-critical.
---
> The subject directory attributes extension is used to convey
> identification attributes (e.g.,nationality) of the subject. The
> extension is defined as a sequence of one or more attributes. This
> extension MUST be non-critical.
# In section 4.2.1.13 (Extended key usage field),
# Clarified that a certificate user can ignore unrecognized values in
# the extended key usage field.
< If the extension is flagged critical, then the certificate MUST be
< used only for one of the purposes indicated.
---
> If the extension is flagged critical, then the certificate MUST only
> be used for one of the purposes indicated. If multiple purposes are
> indicated the application need not recognize all purposes indicated,
> as long as the intended purpose is present and recognized.
# In section 4.2.2.1 (Authority Information Access),
# Clarified what the OCSP access descriptor indicates.
< Status Protocol. Additional access descriptors may be defined in
---
> Status Protocol. When this access descriptor appears in the
> authority information access extension, this indicates the issuer
> provides revocation information for this certificate through the
> named OCSP service. Additional access descriptors may be defined in
# In section 4.2.2.2 (Subject Information Access),
# A new section describing the subject information access extension.
> 4.2.2.2 Subject Information Access
>
> The subject information access extension indicates how to access
> information and services for the subject of the certificate in which
> the extension appears. When the subject is a CA, information and
> services may include certificate validation services and CA policy
> data. When the subject is an end entity, the information describes
> the type of services offered and how to access them. In this case,
> the contents of this extension are defined in the protocol
> specifications for the suported services. This extension may be
> included in subject or CA certificates, and it MUST be non-critical.
>
> id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
>
> SubjectInfoAccessSyntax ::=
> SEQUENCE SIZE (1..MAX) OF AccessDescription
>
> AccessDescription ::= SEQUENCE {
> accessMethod OBJECT IDENTIFIER,
> accessLocation GeneralName }
>
> Each entry in the sequence SubjectInfoAccessSyntax describes the
> format and location of additional information provided by the subject
> of the certificate in which this extension appears. The type and
> format of the information is specified by the accessMethod field; the
> accessLocation field specifies the location of the information. The
> retrieval mechanism may be implied by the accessMethod or specified
> by accessLocation.
>
> This profile defines one accessMethod to be used when the subject is
> a CA, and one access mehod to be used when the subject is an end
> entity. Additional access methods may be defined in the future in
> the protocol specifications for other services.
>
> The id-ad-caRepository OID is used when the subject is a CA, and
> publishes its certificates and CRLs (if issued) in a repository. The
> accessLocation field is defined as a GeneralName, which can take
> several forms. Where the information is available via http, ftp, or
> ldap, accessLocation MUST be a uniformResourceIdentifier. Where the
> information is available via the directory access protocol (dap),
> accessLocation MUST be a directoryName. When the information is
> available via electronic mail, accessLocation MUST be an rfc822Name.
> The semantics of other name forms of of accessLocation (when
> accessMethod is id-ad-caRepository) are not defined by this
> specification.
>
> The id-ad-timeStamping OID is used when the subject offers
> timestamping services using the Time STamp Protocol defined in [PKIX
> TSA]. Where the timestamping services are available via http or ftp,
> accessLocation MUST be a uniformResourceIdentifier. Where the
> timestamping services are available via electronic mail,
> accessLocation MUST be an rfc822Name. Where timestamping services
> are available using TCP/IP, the dNSName and ipAddress name forms may
> be used. The semantics of other name forms of accessLocation (when
> accessMethod is id-ad-timeStamping) are not defined by this
> specification.
>
> Additional access descriptors may be defined in other PKIX
> specifications.
>
> id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
>
> id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
>
> id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
# In section 6 (Certification Path Validation),
# Mostly minor wording changes. Clarifies that relying party can
# supply constraints via "initial state variables".
< Certification path validation procedures for the Internet PKI are
< based on section 12.4.3 of [X.509]. Certification path processing
< verifies the binding between the subject distinguished name and/or
< subject alternative name and subject public key. The binding is lim-
< ited by constraints which are specified in the certificates which
< comprise the path. The basic constraints and policy constraints
< extensions allow the certification path processing logic to automate
< the decision making process.
<
< This section describes an algorithm for validating certification
< paths. Conforming implementations of this specification are not
< required to implement this algorithm, but MUST be functionally
---
> Certification path validation procedures for the Internet PKI are
> based on the algorithm supplied in [X.509]. Certification path
> processing verifies the binding between the subject distinguished
> name and/or subject alternative name and subject public key. The
> binding is limited by constraints which are specified in the
> certificates which comprise the path and the initial state variables
> which are specified by the relying party. The basic constraints and
> policy constraints extensions allow the certification path processing
> logic to automate the decision making process.
>
> This section describes an algorithm for validating certification
> paths. Conforming implementations of this specification are not
> required to implement this algorithm, but MUST provide functionality
# Removed the validity period of the public key from the set of inputs
# required by the algorithm, since it was never used in the algorithm.
< In section 6.1, the text describes basic path validation. This text
< assumes that all valid paths begin with certificates issued by a sin-
< gle "most-trusted CA". The algorithm requires the public key of the
< CA, the CA's name, the validity period of the public key, and any
< constraints upon the set of paths which may be validated using this
< key.
---
> In section 6.1, the text describes basic path validation. Valid paths
> begin with certificates issued by a "most-trusted CA". The algorithm
> requires the public key of the CA, the CA's name, and any constraints
> upon the set of paths which may be validated using this key.
# Clarified the handling of the "most-trusted CA" a bit.
< The "most-trusted CA" is a matter of policy: it could be a root CA in
< a hierarchical PKI; the CA that issued the verifier's own
< certificate(s); or any other CA in a network PKI. The path valida-
< tion procedure is the same regardless of the choice of "most-trusted
< CA."
---
> The selection of a "most-trusted CA" is a matter of policy: it could
> be the top CA in a hierarchical PKI; the CA that issued the
> verifier's own certificate(s); or any other CA in a network PKI. The
> path validation procedure is the same regardless of the choice of
> "most-trusted CA." In addition, different applications may rely on
> different "most-trusted CA", or may accept paths that begin with any
> of a set of "most-trusted CAs."
# Described section 6.3 here for the sake of completeness.
> Section 6.3 describes the steps necessary to determine if a
> certificate is revoked or on hold status when CRLs are the revocation
> mechanism used by the certificate issuer.
>
# Clarified that features described as optional in earlier sections
# may be omitted from this validation algorithm. They are included
# here only for completeness and clarity.
< This text describes an algorithm for X.509 path processing. A con-
< formant implementation MUST include an X.509 path processing pro-
< cedure that is functionally equivalent to the external behavior of
< this algorithm.
<
< This text assumes that there is a single trust anchor for certifica-
< tion path processing, which simplifies the description of the path
< processing procedure. This procedure can be extended to address mul-
< tiple trust anchors, as discussed further in Section 6.2.
---
> This text describes an algorithm for X.509 path processing. A
> conformant implementation MUST include an X.509 path processing
> procedure that is functionally equivalent to the external behavior of
> this algorithm. However, some of the certificate fields processed in
> this algorithm are optional for compliant implementations. Clients
> that do not support these fields may omit the corresponding steps in
> the path validation algorithm.
>
> For example, clients are not required to support the policy mapping
> extension. Clients that do not support this extension may omit the
> path validation steps where policy mappings are processed. Note that
> clients MUST reject the certificate if it contains critical
> extensions that are not supported.
>
> This text describes the trust anchor as an input to the algorithm.
> There is no requirement that the same trust anchor be used to
> validate all certification paths. Different trust anchors may be
> used to validate different paths, as discussed further in Section
> 6.2.
# Minor wording changes.
< (c) user_initial_policy_set: A set of certificate policy identif-
< iers naming the policies that are acceptable to the certificate
< user. The user_initial_policy_set has the special value "any-
< policy" if the user is not concerned about certificate policy.
---
> (c) user-initial-policy-set: A set of certificate policy
> identifiers naming the policies that are acceptable to the
> certificate user. The user-initial-policy-set contains the special
> value any-policy if the user is not concerned about certificate
> policy.
# Removed the issuer unique identifier from the trust anchor
# information (presumably because its use is discouraged).
< (2) optionally, the trusted issuer unique identifier,
< (3) the trusted public key algorithm,
< (4) the trusted public key, and
< (5) optionally, the trusted public key parameters associated
---
>
> (2) the trusted public key algorithm,
>
> (3) the trusted public key, and
>
> (4) optionally, the trusted public key parameters associated
# working_issuer_UID has been removed (although it is still referenced
# later in the algorithm).
< The initialization phase establishes twelve state variables based
---
> The initialization phase establishes eleven state variables based
# working_issuer_UID has been removed
< (k) working_issuer_UID: a distinguished name may be associated
< with an optional unique identifier. The working_issuer_UID is the
< unique identifier that is expected in the next certificate, or the
< value NULL. The working_issuer_UID is initialized to the trusted
< issuer's unique identifier provided in the trust anchor informa-
< tion.
# New behavior in policy processing.
> If no node of depth i in the valid_policy_tree has a
> valid_policy of ID-P but there is a node of depth i with a
> valid_policy of any-policy, then generate a child node of the
> node of depth i-1 that has a valid_policy of any-policy as
> follows:
>
> (i) set the valid_policy to ID-P;
>
> (ii) set the qualifier_set to the qualifier set of the
> policy any-policy in the certificate policies extension of
> certificate i;
>
> (iii) set the criticality_indicator to the criticality of
> the certificate policies extension of certificate i;
>
> (iv) and set the expected_policy_set to the set of
> subjectDomainPolicy values that are specified as equivalent
> to ID-P by the policy mappings extension.
# In section 6.2 (Using the Path Validation Algorithm),
#
# If you want to have different parameters for different trust
# anchors, the old recommendation was to place limitations in the
# self-signed certificates used as the trust anchors. The new
# recommendation is to supply different inputs to the path validation
# procedure.
< The path validation algorithm presented in 6.1 is based on several
< simplifying assumptions (e.g., a single trusted CA that starts all
< valid paths). This algorithm may be extended for cases where the
< assumptions do not hold.
<
< This procedure may be extended for multiple trusted CAs by providing
< a set of self-signed certificates to the validation module. In this
< case, a valid path could begin with any one of the self-signed certi-
< ficates. Limitations in the trust paths for any particular key may
< be incorporated into the self-signed certificate's extensions. In
< this way, the self-signed certificates permit the path validation
< module to automatically incorporate local security policy and
< requirements.
---
> The path validation algorithm describes the process of validating a
> single certification path. While each path begins with a specific
> trust anchor, there is no requirement that all paths validated by a
> particular system share a single trust anchor.
>
> The selection of one or more trusted CAs is a local decision. A
> system may provide any one of its trusted CAs as the trust anchor for
> a particular path. The inputs to the path validation algorithm may
> be different for each path. The inputs used to process a path may
> reflect application-specific requirements or limitations in the trust
> accorded a particular trust anchor. For example, a trusted CA may
> only be trusted for a particular certificate policy. This
> restriction can be expressed through the inputs to the path
> validation procedure.
# In section 7 (References),
# Added a new reference, referred to from the Subject Information
# Access section.
> [PKIX TSA] Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509
> Public Key Infrastructure Time Stamp Protocol,"
> draft-ietf-pkix-time-stamp-12.txt, November, 2000.
# In section A.1 (Explicitly Tagged Module, 1988 Syntax),
# Added two more OIDs for use with the subject information access extension.
> id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
> id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
# In Appendix B (ASN.1 Notes),
# Modified text to reflect the fact that zero is a valid serialNumber.
< CAs MUST force the serialNumber to be a positive integer, that is,
---
> CAs MUST force the serialNumber to be a non-negative integer, that
# Modified text to explicitly require certificate users to support
# serial numbers up to 20 octets in length.
< Given the uniqueness requirements above serial numbers can be
< expected to contain long integers. Certificate users MUST be able to
< handle serialNumber values longer than 32 bits. Conformant CAs MUST
---
> As noted in section 4.1.2.2, serial numbers can be expected to
> contain long integers. Certificate users MUST be able to handle
> serialNumber values up to 20 octets in length. Conformant CAs MUST
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15345 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 07:00:10 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA26456; Wed, 29 Nov 2000 10:01:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v04220804b64ac87da0f6@[171.78.30.107]>
In-Reply-To: <003701c059dd$794ae5d0$0201a8c0@vincent.se>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <3A139374.B6BDD00E@nma.com> <009b01c04fa6$33b92130$0201a8c0@vincent.se> <v04220806b639c6a45afb@[128.33.238.64]> <005001c05067$317ca600$0201a8c0@vincent.se> <v0422081bb649ff014a35@[171.78.30.107]> <003701c059dd$794ae5d0$0201a8c0@vincent.se>
Date: Wed, 29 Nov 2000 09:57:58 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well?
Cc: "PKIX-List" <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Anders,
><snip>
>
>Talking about ACs: I have hard to see that ACs will be "issued" by
>CAs & RAs in the
>usual sense, they will typically be created automatically on demand
>based on information
>in various systems. And distributed to the client's "PSD" or similar - Never.
That's one model, but I have seen and heard briefings on models that
do call for authorities to create and distribute ACs that are managed
in a way analogous to PKCs. There is a potential for more automation
if existing ACLs exist from which to authorize issuance of ACs, since
there often may not be a need for the procedural activities
associated with initial user authentication as per PKCs. However, the
AC issuance procedure may be equivalent to some PKC issuance
procedures, i.e., ones where users are already known and have some
form of online authentication capability. Then the situation is
exactly analogous to issuing an AC on demand based on a pre-existing
ACL.
Steve
Received: from mailf.telia.com (root@mailf.telia.com [194.22.194.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14989 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 06:52:16 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailf.telia.com (8.9.3/8.9.3) with ESMTP id PAA01846 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 15:53:44 +0100 (CET)
Received: from mega (t7o69p167.telia.com [213.65.46.167]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eATErio14834 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 15:53:44 +0100 (CET)
Message-ID: <002901c05a13$f83efd50$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "PKIX-List" <ietf-pkix@imc.org>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-04.txt
Date: Wed, 29 Nov 2000 15:52:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA14990
I took a short look into this (and may have got it all wrong), as I have heard that it would
support XML. It apparently does, what I wonder if, if this is the way to do XML support.
That X509 certs are coded as Base64 blobs is OK, but why must requests
be coded as OIDs?
I.e. all protocols have som kind of implicit API that in ASN.1 is mapped through
OID-based structures but I don't think this is the most appropriate for XML.
This is similar requiring that Java and VisualBasic implementations of an API
must be identically structured in spite of very different language features.
Maybe the idea is that the ASN.1 and XML implementations should always be
aligned and pushed together? I would not base future and potentially
evolving standards like SCVP on such ideas. I.e. a vendor should have the option to
only support one of the paths.
Anders
Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA06569 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 04:24:01 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 0387952; Wed, 29 Nov 2000 07:25:28 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-13-230.bellatlantic.net [141.154.13.230]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id HAA12687; Wed, 29 Nov 2000 07:25:57 -0500
Message-ID: <3A24F672.5AA0CEE8@caveosystems.com>
Date: Wed, 29 Nov 2000 07:28:34 -0500
From: Rich Salz <rsalz@caveosystems.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at>
CC: ietf-pkix@imc.org
Subject: Re: OIDs as URIs
References: <NDBBJJNFOMNNKFDPLCDJEEHHCEAA.Karl.Scheibelhofer@iaik.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
> try to guess waht 1.3.14.3.2.27 means (without browsing into some
> web-directory).
> then try to read {iso(1) identified-organization(3) oiw(14) secsig(3)
> algorithms(2) sha1(27)}.
> i think we do not need discuss, what is easier to read for humans.
But we do! You picked one example that sort of works. But it only sort-of
works:
What's oiw?
What's secsig?
Out of that entire string, the only useful "word" is SHA1. So perhaps
oid:1.3.14.3.2.27#sha-1
where the URI fragment after the # is a comment?
I claim your example is contrived. You also haven't answered my question --
*how* will the words be used by humans?
/r$
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA05621 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 04:09:56 -0800 (PST)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A26AD75B0038; Wed, 29 Nov 2000 13:11:22 +0100
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0 17/November/2000); Wed, 29 Nov 2000 13:09:12 +0100
From: "Karl Scheibelhofer" <Karl.Scheibelhofer@iaik.at>
To: "Rich Salz" <rsalz@caveosystems.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: OIDs as URIs
Date: Wed, 29 Nov 2000 13:09:12 +0100
Message-ID: <NDBBJJNFOMNNKFDPLCDJEEHHCEAA.Karl.Scheibelhofer@iaik.at>
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 IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3A24EDD5.8877AC29@caveosystems.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> -----Original Message-----
> From: Rich Salz [mailto:rsalz@caveosystems.com]
> Sent: Wednesday, November 29, 2000 12:52 PM
> To: Karl Scheibelhofer
> Cc: ietf-pkix@imc.org
> Subject: Re: OIDs as URIs
>
>
> > it should at least be possible to use a kind of NameAndNumberForm.
>
> Why? Under what circumstances is "enterprise-mib" better than "2"?
> We already know that names will hurt machine processing, and humans can
> clearly read numbers. What is the point of having the name? Who will
> be helped, and what will they do with it?
one main reason for expressing OIDs as URIs is that we want to use the
within XML documents. normally one can read a XML document with a text
editor and get a good idea of what it is all about.
if you use pure number OIDs in it, you have normally no idea, what that
means.
try to guess waht 1.3.14.3.2.27 means (without browsing into some
web-directory).
then try to read {iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) sha1(27)}.
i think we do not need discuss, what is easier to read for humans.
regards
Karl Scheibelhofer
--
Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540
Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA02985 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 03:47:27 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 09618327; Wed, 29 Nov 2000 06:48:30 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-13-230.bellatlantic.net [141.154.13.230]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id GAA12614; Wed, 29 Nov 2000 06:49:13 -0500
Message-ID: <3A24EDD5.8877AC29@caveosystems.com>
Date: Wed, 29 Nov 2000 06:51:49 -0500
From: Rich Salz <rsalz@caveosystems.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at>
CC: ietf-pkix@imc.org
Subject: Re: OIDs as URIs
References: <NDBBJJNFOMNNKFDPLCDJMEHCCEAA.Karl.Scheibelhofer@iaik.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
> it should at least be possible to use a kind of NameAndNumberForm.
Why? Under what circumstances is "enterprise-mib" better than "2"?
We already know that names will hurt machine processing, and humans can
clearly read numbers. What is the point of having the name? Who will
be helped, and what will they do with it?
Received: from belcebu.upc.es (belcebu.upc.es [147.83.2.63]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02081 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 03:41:32 -0800 (PST)
Received: from mat.upc.es (mat.upc.es [147.83.39.3]) by belcebu.upc.es (8.8.8+Sun/8.8.8) with ESMTP id MAA13669 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 12:43:00 +0100 (MET)
Received: from mat.upc.es (cript0.upc.es [147.83.39.224]) by mat.upc.es (8.8.8/8.8.8) with ESMTP id MAA02764 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 12:42:27 +0100 (MET)
Message-ID: <3A24EBF2.F67C9403@mat.upc.es>
Date: Wed, 29 Nov 2000 12:43:46 +0100
From: Juan Carlos Castro =?iso-8859-1?Q?Ch=E1vez?= <jcastro@mat.upc.es>
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD BDP81800 (WinNT; U)
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Unsubscribe
Content-Type: multipart/mixed; boundary="------------2CB15C754CABDD992A80E4F0"
This is a multi-part message in MIME format.
--------------2CB15C754CABDD992A80E4F0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--------------2CB15C754CABDD992A80E4F0
Content-Type: text/x-vcard; charset=us-ascii;
name="jcastro.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Juan Carlos Castro Chávez
Content-Disposition: attachment;
filename="jcastro.vcf"
begin:vcard
n:Castro Chávez;Juan Carlos
tel;cell:(34) 649 691 341
tel;work:(34) 93 401 7809
x-mozilla-html:FALSE
org:Universidad Politécnica de Cataluña;Departamento de Matemática Aplicada y Telemática
adr:;;Calle Jordi Girona, 1 i 3 Mod. C3; Lab003a, Campus Nord;;Barcelona;Barcelona;08034
version:2.1
email;internet:jcastro@mat.upc.es
title:Doctorando IngenierÃa Telemática
fn:Juan Carlos Castro Chávez
end:vcard
--------------2CB15C754CABDD992A80E4F0--
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01372 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 03:29:44 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01853; Wed, 29 Nov 2000 06:31:13 -0500 (EST)
Message-Id: <200011291131.GAA01853@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-scvp-04.txt
Date: Wed, 29 Nov 2000 06:31:12 -0500
Sender: nsyracus@cnri.reston.va.us
--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 : Simple Certificate Validation Protocol (SCVP)
Author(s) : A. Malpani, P. Hoffman, R. Housley
Filename : draft-ietf-pkix-scvp-04.txt
Pages :
Date : 28-Nov-00
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not the certificate is valid, a chain
to a trusted root, and so on. SCVP has many purposes, including
simplifying client implementations and allowing companies to centralize
their trust and policy managment.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-04.txt
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-scvp-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:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-scvp-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="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001128134518.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-scvp-04.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001128134518.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA25432 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 02:39:10 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA22329; Wed, 29 Nov 2000 11:40:39 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 29 Nov 2000 11:40:39 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id LAA14798; Wed, 29 Nov 2000 11:40:38 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA02295; Wed, 29 Nov 2000 11:40:38 +0100 (MET)
Date: Wed, 29 Nov 2000 11:40:38 +0100 (MET)
Message-Id: <200011291040.LAA02295@emeriau.edelweb.fr>
To: ietf-pkix@imc.org, phil.griffin@asn-1.com
Subject: Re: OCSP identifiers
Note that the current spec does NOT change the certID syntax
at all, the syntax fortunately adds a wrapper ReqCert,
thus other modules that use certId are not affected,
not that using the certId choice in IMPLICIT ReqCert
would not give the same encoding as IMPLICIT CertId
(if my memories of asn1 rules are correct).
I repeat that the current spec of OCSPv2 does not give
a definition of what is intended to be specified with
the alternatives. Is this intended or not?
Peter
> Michael,
>
> I have been working with Rich Ankney on OCSP issues in
> an X9F3 standard we wished to align with your work and
> definitely support your efforts to amend the certID
> syntax. If I can be of any help with any ASN.1 related
> issues, please let me know.
>
> Phil Griffin
>
>
> Michael Myers wrote:
> >
> > Denis,
> >
> > Regarding the question "Should RFC 2560's certID syntax be amended to
> > accomodate other use cases" you proposed to me offlist and to the WG onlist
> > an ASN.1 syntax to address that need. Given your actions, I concluded that
> > you favored taking this action. Please clarify your position so that I may
> > maintain an accurate consensus count.
> >
Received: from mailg.telia.com (root@mailg.telia.com [194.22.194.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA11307 for <ietf-pkix@imc.org>; Wed, 29 Nov 2000 00:22:15 -0800 (PST)
Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailg.telia.com (8.9.3/8.9.3) with ESMTP id JAA05859; Wed, 29 Nov 2000 09:23:38 +0100 (CET)
Received: from mega (t2o69p24.telia.com [62.20.144.144]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id eAT8Nao10490; Wed, 29 Nov 2000 09:23:37 +0100 (CET)
Message-ID: <003701c059dd$794ae5d0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <3A139374.B6BDD00E@nma.com> <009b01c04fa6$33b92130$0201a8c0@vincent.se> <v04220806b639c6a45afb@[128.33.238.64]> <005001c05067$317ca600$0201a8c0@vincent.se> <v0422081bb649ff014a35@[171.78.30.107]>
Subject: Re: Should PKIX protocols support XML well?
Date: Wed, 29 Nov 2000 09:22:08 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA11344
Steve,
> Many of us manage to participate in multiple WGs in the IETF,
> although it is a time consuming task. So, I don't fear that if a new
> WG were created to focus on XML PKI support that the drain would
> cripple the current PKIX work. if the extent of XML support is of the
> magnitude of what is proposed in SCVP, I don't think there is a need
> for a separate WG. However, if the intent is to create XML parallel
> syntax for all PKIX protocols, any maybe even to mandate support for
> that syntax in clients, CA, etc. then a separate WG, with a charter
> focused on that sort of work is the most appropriate way to proceed.
> Hope the clarification helps.
>
> Steve
>
It does to some extent only as neither you and I know exactly what will be created
in the future as it depends on demand.
Long-term, I anticipate the entire X500 family to be XML-ized, short-term ACs
seem to be a good target as it is a type of item that requires fundamental changes
in client-platforms and CA-systems. Which I BTW do not expect to happen as
solutions like my proprosed XML-AC, and S2ML build on the infrastructure that others
already are creating on top of existing PKI-systems. I.e. e-commerce and banking
using XMLDSIG.
Due to the fact that no mailing-list or BOF-session was granted, I probably will not go to San Diego.
But I intend to write a PKIXML WG charter proposal.
Talking about ACs: I have hard to see that ACs will be "issued" by CAs & RAs in the
usual sense, they will typically be created automatically on demand based on information
in various systems. And distributed to the client's "PSD" or similar - Never.
Anders
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03357 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 23:30:48 -0800 (PST)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A100FEE0142; Wed, 29 Nov 2000 08:32:16 +0100
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0 17/November/2000); Wed, 29 Nov 2000 08:30:04 +0100
From: "Karl Scheibelhofer" <Karl.Scheibelhofer@iaik.at>
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>, <ietf-pkix@imc.org>
Subject: RE: OIDs as URIs
Date: Wed, 29 Nov 2000 08:30:04 +0100
Message-ID: <NDBBJJNFOMNNKFDPLCDJMEHCCEAA.Karl.Scheibelhofer@iaik.at>
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 IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <200011281614.LAA09063@roadblock.missi.ncsc.mil>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> -----Original Message-----
> From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
> Sent: Tuesday, November 28, 2000 5:31 PM
> To: ietf-pkix@imc.org
> Subject: RE: OIDs as URIs
>
>
> From: "Karl Scheibelhofer" <Karl.Scheibelhofer@iaik.at>
>
> > > > it is not human readable.
> > >
> > > This is not needed either.
> >
> > for use in XML i would heavily recommend that it is human readable. as i
> > already stated in another message, this was a design goal for XML: "XML
> > documents should be human-legible and reasonably clear." i think this
> > advantage should not be underestimated.
>
>
> OIDs are registered by number. The human-readable strings are comments
> added for convenience; there may be zero, one, or more strings used
> to represent a particular OID arc, and the suggested values for such
> strings can be changed if the organization registering them wishes
> them changed.
>
> The notation for object identifiers defined in X.680 is a list of
> components, where each component can be a NameForm, a NumberForm, or
> a NameAndNumberForm:
>
> * { itu-t(0) identified-organization(4) etsi(0)
> electronic-signature-standard(1733) part1(1) idupMechanism(4)
> etsiESv1(1) }
>
> * { 0 4 0 1733 1 4 1 }
>
> * { itu-t identified-organization etsi(0) 1733 1 4 etsiESv1(1) }
>
>
> But:
>
> "The semantics of an object identifier value are defined by reference
> to an object identifier tree. ... Each arc of the tree is labelled
> by an object identifier component which is a numeric value. ... Thus
> an object is uniquely and unambiguously identified by the sequence of
> numeric values labelling the arcs in a path from the root to the vertex
> allocated to the object."
>
>
> Providing the option for a human-readable XML encoding is a reasonable
> goal, but there is a significant risk that XML software will treat the
> human-readable portion of the encoding not as a comment but as
> significant.
> This results in a situation where a comparison of two identical OIDs
> could give an answer of "not equal".
>
> Any XML encoding of OIDs MUST permit a numeric-only representation, and
> MUST ensure that the semantics of OIDs are preserved when non-numeric
> representations are used.
i agree that a number-only presentation should be supported. i think that is
even necessary, because it it not required for all arcs to have a name. but
it should at least be possible to use a kind of NameAndNumberForm.
personally, i would even avoid the name-only form. it would be quite hard to
get a number-only presentation out of it.
for comparison, it will be necessary to define under what conditions two URI
presentations of OIDs must be considered equivalent.
regards
Karl
Received: from mailmc.ec.com.cn ([210.25.6.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22449 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 18:55:11 -0800 (PST)
From: yezhen@ec.com.cn
Received: from localhost (root@localhost) by mailmc.ec.com.cn (8.9.3 (PHNE_18979)/8.9.3) with SMTP id KAA04605 for ietf-pkix@imc.org; Wed, 29 Nov 2000 10:44:58 +0800 (EAT)
X-OpenMail-Hops: 1
Date: Wed, 29 Nov 2000 10:44:53 +0800
Message-Id: <H000018200d8b473@MHS>
Subject: Unsubscribe
MIME-Version: 1.0
TO: ietf-pkix@imc.org
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA21293 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 18:08:18 -0800 (PST)
Received: from louise.parc.xerox.com ([13.2.118.28]) by alpha.xerox.com with SMTP id <62229(2)>; Tue, 28 Nov 2000 18:09:39 PST
Received: from parc.xerox.com ([13.1.100.95]) by louise.parc.xerox.com with SMTP id <359567>; Tue, 28 Nov 2000 18:09:24 PST
Message-ID: <3A24657C.A82C4060@parc.xerox.com>
Date: Tue, 28 Nov 2000 18:10:04 PST
From: "D.K. Smetters" <smetters@parc.xerox.com>
Organization: Xerox Parc
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
CC: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>, ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <613B3C619C9AD4118C4E00B0D03E7C3E136663@exchange.valicert.com> <3A14DC54.8A1EB912@stroeder.com> <v04220818b649f9e917d3@[171.78.30.107]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
While you might have to live with a CA keeping the same DN, you
might certainly expect them not to issue certs that repeat previously-
used serial numbers...
--Diana
Stephen Kent wrote:
>
> At 8:20 AM +0100 11/17/00, Michael Ströder wrote:
> >Frank Balluffi wrote:
> > >
> > > Rich,
> > >
> > > If RFC 2459 says:
> > >
> > > The serial number is an integer assigned by the CA to each
> > > certificate. It MUST be unique for each certificate issued by a
> > > given CA (i.e., the issuer name and serial number identify a unique
> > > certificate).
> > >
> > > why are issuer + serial number, and issuer + subject + serial number not
> > > unique? Is this an example of reality not agreeing with theory?
> >
> >As I understand it Denis pointed out that this might not be unique
> >in case of a issuer key compromise (and the issuer DN being reused
> >in the new issuer cert).
> >
> >IMHO it should be forbidden to reuse the issuer DN in this serious
> >case anyway.
> >
> >Ciao, Michael.
>
> It's probably not reasonable to require a CA to change its name under
> such circumstances, although they might want to do so for PR purposes
> :-)
>
> Steve
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19100 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 16:38:23 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA05094; Tue, 28 Nov 2000 19:39:48 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v0422081bb649ff014a35@[171.78.30.107]>
In-Reply-To: <005001c05067$317ca600$0201a8c0@vincent.se>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <3A139374.B6BDD00E@nma.com> <009b01c04fa6$33b92130$0201a8c0@vincent.se> <v04220806b639c6a45afb@[128.33.238.64]> <005001c05067$317ca600$0201a8c0@vincent.se>
Date: Tue, 28 Nov 2000 19:37:00 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well?
Cc: "PKIX-List" <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
><snip>
>
>This is one way to do this. Don't you see a risk of losing a lot of
>good people to
>this new WG? I think this question is of such magnitude that it requires a
>*descision* from the chairs and the members.
>
>Or do you expect the XML-PKI WG to consist of me an a few other
>"kinky" developers?
>Why not try to estimate how many of current PKIX:ers that would put
>their main focus
>in the new WG?
Many of us manage to participate in multiple WGs in the IETF,
although it is a time consuming task. So, I don't fear that if a new
WG were created to focus on XML PKI support that the drain would
cripple the current PKIX work. if the extent of XML support is of the
magnitude of what is proposed in SCVP, I don't think there is a need
for a separate WG. However, if the intent is to create XML parallel
syntax for all PKIX protocols, any maybe even to mandate support for
that syntax in clients, CA, etc. then a separate WG, with a charter
focused on that sort of work is the most appropriate way to proceed.
Hope the clarification helps.
Steve
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19084 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 16:38:22 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA05090; Tue, 28 Nov 2000 19:39:46 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v0422081ab649fe963111@[171.78.30.107]>
In-Reply-To: <613B3C619C9AD4118C4E00B0D03E7C3E182B07@exchange.valicert.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E182B07@exchange.valicert.com>
Date: Tue, 28 Nov 2000 19:31:03 -0500
To: Peter Williams <peterw@valicert.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Should PKIX protocols support XML well?
Cc: PKIX-List <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Peter,
thanks so much. However, someone else already provided me with a
concise explanation, privately, and without the need for me to
retrieve and read the cited documents.
Steve
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18425 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 16:18:42 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA04037; Tue, 28 Nov 2000 19:19:48 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v04220818b649f9e917d3@[171.78.30.107]>
In-Reply-To: <3A14DC54.8A1EB912@stroeder.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E136663@exchange.valicert.com> <3A14DC54.8A1EB912@stroeder.com>
Date: Tue, 28 Nov 2000 19:11:36 -0500
To: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: OCSP identifiers
Cc: ietf-pkix@imc.org
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA18426
At 8:20 AM +0100 11/17/00, Michael Ströder wrote:
>Frank Balluffi wrote:
> >
> > Rich,
> >
> > If RFC 2459 says:
> >
> > The serial number is an integer assigned by the CA to each
> > certificate. It MUST be unique for each certificate issued by a
> > given CA (i.e., the issuer name and serial number identify a unique
> > certificate).
> >
> > why are issuer + serial number, and issuer + subject + serial number not
> > unique? Is this an example of reality not agreeing with theory?
>
>As I understand it Denis pointed out that this might not be unique
>in case of a issuer key compromise (and the issuer DN being reused
>in the new issuer cert).
>
>IMHO it should be forbidden to reuse the issuer DN in this serious
>case anyway.
>
>Ciao, Michael.
It's probably not reasonable to require a CA to change its name under
such circumstances, although they might want to do so for PR purposes
:-)
Steve
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17675 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 15:58:31 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA02677; Tue, 28 Nov 2000 18:59:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v04220814b649f5db23f4@[171.78.30.107]>
In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F401C5BAB6@vhqpostal.verisign.com>
References: <2F3EC696EAEED311BB2D009027C3F4F401C5BAB6@vhqpostal.verisign.com>
Date: Tue, 28 Nov 2000 18:55:50 -0500
To: Michael Myers <MMyers@verisign.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: OCSP identifiers
Cc: ietf-pkix@imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 11:39 AM -0800 11/28/00, Michael Myers wrote:
>On Tuesday, November 28, 2000 1:17 AM, Simon Tardell wrote:
> > count me to the opposition then.
>
>On Tuesday, November 28, 2000 8:46 AM, Peter Sylvester wrote:
> > Mike, you may count me in a similar way as Denis.
>
>
>All:
>
>In addition, I spoke offlist with Paul Hoffman yesterday who made it clear
>to me that my understanding of his opposition was in error. Paul never
>voiced such an opinion on list. So with respect to the question "Should RFC
>2560's certID syntax be amended to accomodate other use cases" we have:
>
>9 in favor (minus Tardell, plus Sylvester)
>2 opposed (minus Hoffman, plus Tardell)
>
>Anyone else care to offer an opinion?
>
>Mike
Yes,
I think there is ample support and technical rationale for this
change, but it's significant enough to reset advancement for the OCSP
document, i.e., v2 is a new standard. You'll have to decide if it
supercedes v1, etc. I'm awfully far behind on my e-mail. so maybe
I've missed this part of the debate, but what are the plans re OCSP
v1, i.e., since we all loathe parallel, mostly equivalent versions of
standards, is the proposal to replace v1 with v2, and denigrate the
use of v1?
Just asking ...
Steve
Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17476 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 15:56:00 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id <V9A7W9SV>; Tue, 28 Nov 2000 15:51:43 -0800
Message-ID: <1BE57AA01A5ED411866500B0D049657B42A573@exchange.cylink.com>
From: "Covey, Carlin" <ccovey@cylink.com>
To: "'Michael Myers'" <MMyers@verisign.com>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Tue, 28 Nov 2000 15:51:42 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Mike,
Since we seem to be taking a straw poll here, let me cast my (uncertified)
vote in favor of OCSPv2's proposal to amend RFC 2560's certID syntax.
Those who are opposed are free to use the version 1 certID syntax in
their client's queries, and to respond with "malformedRequest" if their
responder receives some other type of certificate identifier.
However, going forward it would be nice if there were a more graceful
means for a version 2 responder to tell a client that this responder
does not recognize the certificate identifier in the client's request.
Regards,
Carlin Covey
Cylink Corp.
> -----Original Message-----
> From: Michael Myers [mailto:MMyers@verisign.com]
> Sent: Monday, November 27, 2000 2:34 PM
> To: Ambarish Malpani; 'Michael Myers'; Denis Pinkas
> Cc: ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
<snip>
> Among those who spoke on-list regarding OCSPv2's proposal to amend RFC
> 2560's certID syntax, PKIX has:
>
> 9 in favor
> 2 opposed
>
<snip>>
>
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13558 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 14:09:40 -0800 (PST)
Received: from asn-1.com (user-2ivf245.dialup.mindspring.com [165.247.136.133]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA08670 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 17:11:06 -0500 (EST)
Message-ID: <3A2482A4.ED9D958D@asn-1.com>
Date: Tue, 28 Nov 2000 23:14:28 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: Re: OCSP identifiers
References: <C813C1768C55D3119D200090277AEECA817281@vhqpostal.verisign.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael,
I have been working with Rich Ankney on OCSP issues in
an X9F3 standard we wished to align with your work and
definitely support your efforts to amend the certID
syntax. If I can be of any help with any ASN.1 related
issues, please let me know.
Phil Griffin
Michael Myers wrote:
>
> Denis,
>
> Regarding the question "Should RFC 2560's certID syntax be amended to
> accomodate other use cases" you proposed to me offlist and to the WG onlist
> an ASN.1 syntax to address that need. Given your actions, I concluded that
> you favored taking this action. Please clarify your position so that I may
> maintain an accurate consensus count.
>
> Mike
>
> On Monday, November 27, 2000 1:12 PM, Michael Myers wrote:
> > > In favor
> > > --------
> > > Michael Myers
> > > Carlisle Adamas
> > > Stephen Farrell
> > > Rich Ankney
> > > Denis Pinkas
> > > (noting that Denis proposes an alternative means
> > > of expanding RFC 2560's certID.)
>
> On Tuesday, November 28, 2000 5:17 AM, Denis Pinkas wrote:
> >
> > !?!?!? Please, Mike, count me on the OPPOSED side.
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06947 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 12:02:49 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA20868 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 12:00:14 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNFTNN1K>; Tue, 28 Nov 2000 12:04:15 -0800
Message-ID: <C813C1768C55D3119D200090277AEECA817281@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: RE: OCSP identifiers
Date: Tue, 28 Nov 2000 12:04:15 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Denis,
Regarding the question "Should RFC 2560's certID syntax be amended to
accomodate other use cases" you proposed to me offlist and to the WG onlist
an ASN.1 syntax to address that need. Given your actions, I concluded that
you favored taking this action. Please clarify your position so that I may
maintain an accurate consensus count.
Mike
On Monday, November 27, 2000 1:12 PM, Michael Myers wrote:
> > In favor
> > --------
> > Michael Myers
> > Carlisle Adamas
> > Stephen Farrell
> > Rich Ankney
> > Denis Pinkas
> > (noting that Denis proposes an alternative means
> > of expanding RFC 2560's certID.)
On Tuesday, November 28, 2000 5:17 AM, Denis Pinkas wrote:
>
> !?!?!? Please, Mike, count me on the OPPOSED side.
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04510 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 11:38:10 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA10772 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 11:41:12 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNF229ZP>; Tue, 28 Nov 2000 11:39:37 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BAB7@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Tue, 28 Nov 2000 11:39:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA04511
Denis,
I will try again with responses embedded below for full context.
Mike
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Tuesday, November 28, 2000 2:37 AM
> To: Michael Myers
> Cc: ietf-pkix@imc.org
> Subject: Re: OCSP identifiers
>
>
> Michael,
>
> I pick up this message to tell you that:
>
> > Dave,
> >
> > > On Monday, November 20, 2000 8:58 AM you said in part:
> > >
> > > CRL-driven [OCSP] responders are a requirement in my
> > > environment, and OCSP products which cannot be fed
> > > by CRLs will not be purchased.
> >
> > When I said that "OCSP isn't and should't be tied to CRLs",
> I was observing
> > that CRLs are one means for a CA to store the data needed by an OCSP
> > responder. Alternatives exist; these include direct
> database lookup or an
> > LDAP-based query of a directory. We must preserve that
> flexibility. RFC
> > 2560 enables use of CRLs in any variation. There's neither
> intent nor
> > proposal to remove that support.
>
> 1° I agree with your text. The implication is that any basic status
> revocation response should be built using only information
> that is present
> in "fresh" CRLs. This may be self-evident, but it is better to say it.
First you say, "I agree with your text" (which asserts that CRLs aren't
required but rather their use is enabled), then you say that basic response
should be built using ONLY [my emphasis] information present in fresh CRLs.
These statements cancel each other out as far as I'm able to parse them.
Please clarify.
>
> 2° I am still awaiting a response from you on my previous
> E-mails. Since you
> might not remember, here is now (for the third time), the
> questions that I
> raised:
I'll try again below with full context included.
>
> ==============================================================
> ==========
>
> E-mail from November, 15:
>
> Mike,
>
> A few, but important comments on this E-mail sent last week.
>
> > Russ, thanks for getting this debate kicked off. After all
> the work various
> > of us have put into this issue, I was beginning to think no
> one cared.
> >
> > All, as to the debate:
> >
> > Let's hear from everybody before we make a decision.
> > ----------------------------------------------------
> > Thanks to all who have read the IDs and provided comments
> (especially Denis
> > Pinkas). But since active WG members have taken time out
> of their busy
> > schedules to improve the IDs, I think it only fair that
> final judgement be
> > witheld until those contributions are folded into a revised
> version for our
> > consideration in San Diego. At that time it might be more
> appropriate to
> > decide between the two.
> >
> > It's DPV vs. SCVP
> > -----------------
> > OCSP-X has expired; DPV and DPD replace that initial work.
> The requirement
> > we're all most concerned about is delegated path validation
> (although
> > delegated path discovery has it's use). So it really comes
> down to DPV+DPD
> > vs. SCVP since OCSP is already RFC 2560. DPV is little
> more than an OID and
> > a corresponding semantic; it simply puts more meat behind
> 2560's notion of
> > "good".
>
Denis said:
> I disagree with this last statement. Extensions allows to request new
> services. The request for each every new service may fail or
> succeed. This
> means that each extension will have to carry the result of
> the request for
> the new service. This also means that the current status will
> only carry the
> response to a *status revocation request*, but will not carry
> any additional
> meaning. "Good" is not the appropriate term to be used: "not
> revoked" is the
> right term and should be used instead, when we revised OCSP.
>
Response:
On 11/17 under the subject "Re: DPV vs. SCVP", in response to your proposal
to change "good" back to "not revoked" I responded in part as follows:
"It's my sense that once the IETF makes a decision that leads to an RFC, we
should be very cautious in recanting on those recommendations . . . . It's
my opinion that we must think through a reset of the "good" and "unknown"
status responses very carefully . . . . I look to the chairs for guidance
to help me ensure that the IETF process is fully respected as we go forward
. . . ."
If your definition of "response" means "the I-D hasn't been changed as I
asked." that much is true for the reasons I cited above. However, and as
I've said repeatedly, I remain open to strong consensus from the WG on your
proposal or equivalently direction from the chairs.
While I haven't conferred with my co-authors on this point, it would be
useful to know if you would find acceptable an expansion of the CertStatus
field of BasicOCSPResponse to include "not revoked" among the current
"good", "revoked" and "unknown", with corresponding amendments to the
related semantic text.
> > DPD is only a bit more along these same lines of design.
> >
> > They're going to do it anyway.
> > ------------------------------
> > DPV and DPD are nothing more than proposed standard
> extensions to the
> > already existing extension hooks in 2560. Given the
> availablility of those
> > hooks, there's nothing to stop any environment from doing
> precisely this, if
> > only to establish a closed system-level solution. Given
> that, it's better
> > that we take responsible action to promote Internet
> interoperability via a
> > standard means of doing so in the event that such closed
> environments may
> > someday find it useful to interoperate.
>
Denis said:
> The real advantage to add DPV and DPD to OCSP is to be able
> to support both
> a revocation status request and DPV or DPV+DPD in a single request. It
> should however be noticed that a response to a status
> revocation request is
> not mandatory since the server may well return a "revocation
> status unknown"
> response, but still respond to a DPD (Delegated Path
> Discovery) for the
> certificate.
>
>
Response:
Again, on 11/17 under the subject "Re: DPV vs. SCVP", I responded in part as
follows:
"I had hoped that you considered my prior emails as responsive. Some of
your comments I didn't take to be actionable in the absence of a broader
consensus. I'll take another look at them today to see if I missed
something obvious."
Would consider responsive my ad-hoc proposal above to consider expansion of
the spectrum of CertStatus values in BasicOCSPResponse?
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04473 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 11:38:04 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA19469 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 11:35:29 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNFTNMRY>; Tue, 28 Nov 2000 11:39:30 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BAB6@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Tue, 28 Nov 2000 11:39:30 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
On Tuesday, November 28, 2000 1:17 AM, Simon Tardell wrote:
> count me to the opposition then.
On Tuesday, November 28, 2000 8:46 AM, Peter Sylvester wrote:
> Mike, you may count me in a similar way as Denis.
All:
In addition, I spoke offlist with Paul Hoffman yesterday who made it clear
to me that my understanding of his opposition was in error. Paul never
voiced such an opinion on list. So with respect to the question "Should RFC
2560's certID syntax be amended to accomodate other use cases" we have:
9 in favor (minus Tardell, plus Sylvester)
2 opposed (minus Hoffman, plus Tardell)
Anyone else care to offer an opinion?
Mike
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29369 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 10:42:56 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA295180; Tue, 28 Nov 2000 13:43:42 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id NAA139020; Tue, 28 Nov 2000 13:42:47 -0500
Importance: Normal
Subject: RE: I-D ACTION:draft-ietf-pkix-technr-02.txt
To: Hal Lockhart <hal.lockhart@entegrity.com>
Cc: ietf-pkix@imc.org
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF455BC323.A2054E8F-ON852569A5.0066198E@somers.hqregion.ibm.com>
From: "Tom Gindin" <tgindin@us.ibm.com>
Date: Tue, 28 Nov 2000 13:44:04 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Build V506_11152000 |November 15, 2000) at 11/28/2000 01:44:20 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
The main changes are in the determination of what the last acceptable
revocation time is in 2-way NR. Statements were also added to support the
inclusion of an NR policy identifier in a receipt, as given in ISO 13888
for NR tokens, and about which revocations of a third-party certificate
would compromise NR and which would not.
Thanks for your kind remarks,
Tom Gindin
Hal Lockhart <hal.lockhart@entegrity.com> on 11/28/2000 12:28:26 PM
To: Tom Gindin/Watson/IBM@IBMUS, ietf-pkix@imc.org
cc:
Subject: RE: I-D ACTION:draft-ietf-pkix-technr-02.txt
> I have posted this draft with the intention of
> publishing it as an
> Informational RFC. The WG chairs are aware of this intent, and they
> approve of my proposing its publication.
>
> Tom Gindin
I think it is very useful and now routinely point people to it whenever I
hear them throwing around the term non-repudiation to refer to anything
that
involves a digital signature.
Can you summarize the changes from draft 1? I can't find my copy.
Hal
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28794 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 10:30:27 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA16398; Tue, 28 Nov 2000 19:31:44 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 28 Nov 2000 19:31:44 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA11632; Tue, 28 Nov 2000 19:31:43 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA02009; Tue, 28 Nov 2000 19:31:42 +0100 (MET)
Date: Tue, 28 Nov 2000 19:31:42 +0100 (MET)
Message-Id: <200011281831.TAA02009@emeriau.edelweb.fr>
To: Peter.Sylvester@EdelWeb.fr, MMyers@verisign.com, simon.tardell@smarttrust.com
Subject: RE: OCSP identifiers
Cc: ietf-pkix@imc.org
>
> Peter,
>
> Wouldn't it suffice to allow to pass a null value for issuer key hash (which
> would mean that the responder would have to forego that check, of course)?
If I remember it right, this was the option chosen somewhere else in
implementation requirement to support some signature law. There was
also some more or less violent discussion two years ago about this.
I was actually tempted to propose this in my message :-) but a
little provocation with some 'larger' scope seemed more appropriate.
I would not be against this option.
> While still a modification to the protocol it is quite a bit smaller than
> the current OCSP v2 draft... Also, if you don't understand null issuer key
> hash values, you would presumably respond "unknown" which seems the correct
> answer if you insist on having the issuer key hash sent with the request.
Seems reasonable.
> If we allow not to pass issuer and serial we're still in the situation where
> the client can choose to pass an identifier which the responder has no
> chance of resolving, and it has no way of telling "use this type of
> identifier instead" (at least in a way that is distinguishable from "you
> botched up your DER-encoding").
Right, I am not really convinced that allowing just a few alternatives
as they are now, in particular certhash, name are all what could be
imagined as a service. Are we going to use OCSP as a lookup protocol to
support 'give me the current encryption cert for "name"' for example?
> I think that the extension I am proposing should not have the semantics
> "this is the certHash, it can also be used to identify the cert", but rather
> "check if the cert identified by CertID has this certHash". The rationale is
Well, you can have both meanings. basically I agree with your principle.
> that I think it is important that as much as possible of the semantics of
> the response is possible to deduce from the response itself. When used in an
> online fashion it may be enough that the response is just of a
> "go/no-go"-type, but when preserved for posterity, e.g. to include in some
> kind of evidence archival of a notarization service, it could be of
> importance that you can see the individual assertions ("yes, revocation has
> been checked for, but no, the responder did not answer about issuance"). So,
> with a request extension of the type "check if the cert identified by CertID
> has this certHash" a responder that can perform this kind of check would
> return the corresponding response extension with the same certHash and some
> status code (yes, no, unknown). OTOH a responder that does not understand
> this extension would not return any response extension at all [corresponding
> to that particular request extension], but still be able to tell the
> revocation status of the cert.
Yes.
>
> Simon.
>
> PS Mike, I'd like to remind you of the clarification to RFC 2560 that
> Ambarish proposed on this list on Aug 21 (RFC 2560 - OCSP - Clarification).
> They are (of course) equally applicable to the would-be OCSP v2 and I think
> it would be wise to apply them and reevaluate the certificate identifiers in
> the light of those clarifications. DS
All people who have followed the discussion seem to get boared about the
small wording changes, that seems the main reason for slow movement.
But one should not forget that there are people who read the text the first
time without ever having participated to the discussions.
Received: from pierce.llnl.gov (pierce.llnl.gov [128.115.41.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27122 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 09:55:12 -0800 (PST)
Received: from painhouse.llnl.gov (painhouse.llnl.gov [128.115.54.70]) by pierce.llnl.gov (8.8.8/LLNL-3.0.2/llnl.gov-5.1) with ESMTP id JAA00622 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 09:56:08 -0800 (PST)
Message-Id: <5.0.0.25.2.20001128095716.026737f0@popsicle.llnl.gov>
X-Sender: e708550@popsicle.llnl.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 28 Nov 2000 09:57:49 -0800
To: ietf-pkix@imc.org
From: "Frank W. Ploof" <ploof1@llnl.gov>
Subject: Unsubscribe
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_92095265==_.ALT"
--=====================_92095265==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Frank W. Ploof Entrust Ready
PKI Project Lead
Lawrence Livermore National Laboratory
Livermore, Ca. 94551
Ph. 925-422-6990
--=====================_92095265==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<br>
<x-sigsep><p></x-sigsep>
<font size=3>Frank W.
Ploof
</font><font size=3 color="#0000FF">Entrust Ready<br>
</font><font size=3>PKI Project Lead<br>
Lawrence Livermore National Laboratory<br>
Livermore, Ca. 94551<br>
Ph. 925-422-6990<br>
</font></html>
--=====================_92095265==_.ALT--
Received: from internet.across ([213.212.5.232]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA23857 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 09:28:59 -0800 (PST)
Received: FROM acrossw01.across BY internet.across ; Tue Nov 28 18:32:09 2000 +0100
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <XLAPN1F1>; Tue, 28 Nov 2000 18:28:11 +0100
Message-ID: <E5C2786F90B4D4119A200008C716F45D269FE5@acrossw01.acrosswireless.com>
From: Simon Tardell <simon.tardell@smarttrust.com>
To: "'Peter Sylvester'" <Peter.Sylvester@EdelWeb.fr>, MMyers@verisign.com
Cc: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Tue, 28 Nov 2000 18:28:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
> Mike, you may count me in a similar way as Denis.
>
> On one hand I support Simon Tardells argumentation
> about extensions, i.e. for example, if a client or
> a server wants to provide a real cert, then this
> can be done as a Singlerequestextension.
>
> On the other hand there is some need to change:
> it had been discussed years ago that the certID
> syntax always requires that the client need basically
> be in possession of the CA cert of the client.
[...]
> To come close to an alternative:
>
> Allow a zero length certId which then MUST be accompagnied by
> a singleRequestExtension for another identification forms.
[...]
Peter,
Wouldn't it suffice to allow to pass a null value for issuer key hash (which
would mean that the responder would have to forego that check, of course)?
While still a modification to the protocol it is quite a bit smaller than
the current OCSP v2 draft... Also, if you don't understand null issuer key
hash values, you would presumably respond "unknown" which seems the correct
answer if you insist on having the issuer key hash sent with the request.
If we allow not to pass issuer and serial we're still in the situation where
the client can choose to pass an identifier which the responder has no
chance of resolving, and it has no way of telling "use this type of
identifier instead" (at least in a way that is distinguishable from "you
botched up your DER-encoding").
I think that the extension I am proposing should not have the semantics
"this is the certHash, it can also be used to identify the cert", but rather
"check if the cert identified by CertID has this certHash". The rationale is
that I think it is important that as much as possible of the semantics of
the response is possible to deduce from the response itself. When used in an
online fashion it may be enough that the response is just of a
"go/no-go"-type, but when preserved for posterity, e.g. to include in some
kind of evidence archival of a notarization service, it could be of
importance that you can see the individual assertions ("yes, revocation has
been checked for, but no, the responder did not answer about issuance"). So,
with a request extension of the type "check if the cert identified by CertID
has this certHash" a responder that can perform this kind of check would
return the corresponding response extension with the same certHash and some
status code (yes, no, unknown). OTOH a responder that does not understand
this extension would not return any response extension at all [corresponding
to that particular request extension], but still be able to tell the
revocation status of the cert.
Simon.
PS Mike, I'd like to remind you of the clarification to RFC 2560 that
Ambarish proposed on this list on Aug 21 (RFC 2560 - OCSP - Clarification).
They are (of course) equally applicable to the would-be OCSP v2 and I think
it would be wise to apply them and reevaluate the certificate identifiers in
the light of those clarifications. DS
Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
simon.tardell@smarttrust.com
Work smarter! http://www.smarttrust.com/career
Received: from indy.gradient.com (root@indy.gradient.com [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23662 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 09:27:40 -0800 (PST)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id MAA20222; Tue, 28 Nov 2000 12:29:04 -0500 (EST)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id <XVTBY79M>; Tue, 28 Nov 2000 12:28:28 -0500
Message-ID: <899128A30EEDD1118FC900A0C9C74A34BA9493@bigbird.gradient.com>
From: Hal Lockhart <hal.lockhart@entegrity.com>
To: "'Tom Gindin'" <tgindin@us.ibm.com>, ietf-pkix@imc.org
Subject: RE: I-D ACTION:draft-ietf-pkix-technr-02.txt
Date: Tue, 28 Nov 2000 12:28:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"
> I have posted this draft with the intention of
> publishing it as an
> Informational RFC. The WG chairs are aware of this intent, and they
> approve of my proposing its publication.
>
> Tom Gindin
I think it is very useful and now routinely point people to it whenever I
hear them throwing around the term non-repudiation to refer to anything that
involves a digital signature.
Can you summarize the changes from draft 1? I can't find my copy.
Hal
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19535 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 08:44:18 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA15218; Tue, 28 Nov 2000 17:45:38 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 28 Nov 2000 17:45:38 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA11067; Tue, 28 Nov 2000 17:45:37 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA01976; Tue, 28 Nov 2000 17:45:36 +0100 (MET)
Date: Tue, 28 Nov 2000 17:45:36 +0100 (MET)
Message-Id: <200011281645.RAA01976@emeriau.edelweb.fr>
To: MMyers@verisign.com
Subject: RE: OCSP identifiers
Cc: ietf-pkix@imc.org
Mike, you may count me in a similar way as Denis.
On one hand I support Simon Tardells argumentation
about extensions, i.e. for example, if a client or
a server wants to provide a real cert, then this
can be done as a Singlerequestextension.
On the other hand there is some need to change:
it had been discussed years ago that the certID
syntax always requires that the client need basically
be in possession of the CA cert of the client.
Formally, the semantics of the choice are not described
in the current text, only 4.1.2 mentions the
initial version. Not knowing what 'certHash' and
what 'name' doesn't seem good.
To come close to an alternative:
Allow a zero length certId which then MUST be accompagnied by
a singleRequestExtension for another identification forms.
You might add some forms in the v2 draft, but then
the semantics need to be explained.
PS
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17677 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 08:37:14 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA09069 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 11:14:03 -0500 (EST)
Message-Id: <200011281614.LAA09063@roadblock.missi.ncsc.mil>
Date: Tue, 28 Nov 2000 11:30:34 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: RE: OIDs as URIs
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: qygugLoBdYeU0xvciYlB4g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
From: "Karl Scheibelhofer" <Karl.Scheibelhofer@iaik.at>
> > > it is not human readable.
> >
> > This is not needed either.
>
> for use in XML i would heavily recommend that it is human readable. as i
> already stated in another message, this was a design goal for XML: "XML
> documents should be human-legible and reasonably clear." i think this
> advantage should not be underestimated.
OIDs are registered by number. The human-readable strings are comments
added for convenience; there may be zero, one, or more strings used
to represent a particular OID arc, and the suggested values for such
strings can be changed if the organization registering them wishes
them changed.
The notation for object identifiers defined in X.680 is a list of
components, where each component can be a NameForm, a NumberForm, or
a NameAndNumberForm:
* { itu-t(0) identified-organization(4) etsi(0)
electronic-signature-standard(1733) part1(1) idupMechanism(4) etsiESv1(1) }
* { 0 4 0 1733 1 4 1 }
* { itu-t identified-organization etsi(0) 1733 1 4 etsiESv1(1) }
But:
"The semantics of an object identifier value are defined by reference
to an object identifier tree. ... Each arc of the tree is labelled
by an object identifier component which is a numeric value. ... Thus
an object is uniquely and unambiguously identified by the sequence of
numeric values labelling the arcs in a path from the root to the vertex
allocated to the object."
Providing the option for a human-readable XML encoding is a reasonable
goal, but there is a significant risk that XML software will treat the
human-readable portion of the encoding not as a comment but as significant.
This results in a situation where a comparison of two identical OIDs
could give an answer of "not equal".
Any XML encoding of OIDs MUST permit a numeric-only representation, and
MUST ensure that the semantics of OIDs are preserved when non-numeric
representations are used.
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14583 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 08:24:51 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA56852; Tue, 28 Nov 2000 17:32:22 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA21122; Tue, 28 Nov 2000 17:25:40 +0100
Message-ID: <3A23DC85.160229BA@bull.net>
Date: Tue, 28 Nov 2000 17:25:41 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Carlisle Adams <carlisle.adams@entrust.com>
CC: ietf-pkix@imc.org, Michael Myers <MMyers@verisign.com>
Subject: Re: OCSP identifiers
References: <DD62792EA182FF4E99C2FBC07E3053BD053E9F@sottmxs09.entrust.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Carlisle,
We basically agree in principle. However, I have some difficulties to eat,
discuss and write at the same time. So a lunch is certainly not the best way
to handle this problem. Why don't you prepare a first shot and sent it on
the list ? If we have some minor disagreements, then we can certainly
discuss these during a lunch time. However, knowing that you are already
booked for a lunch on Wednesday and that you will not be there on monday the
number of remaining lunches gets very limited.
:-)
Denis
> Hi Denis,
>
> ----------
> From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net]
> Sent: Tuesday, November 28, 2000 10:32 AM
> To: Carlisle Adams
> Cc: ietf-pkix@imc.org; Michael Myers
> Subject: Re: OCSP identifiers
>
> Carlisle,
>
> I am clearly opposed to the current OCSP v2 proposal, I am not
> opposed in
> principle to extensions, ... IF a rational is provided for these
> extensions
> AND we care for OCSCP v1 backward compatibility. In an E-mail posted
> to Mike
> this morning (Paris time), I raised a point raised much earlier,
> which
> remains to be answered:
>
> "Besides the ASN.1, explanations would need to be given to tell which
>
> combinations of these parameters make sense. The problem is that for
> the
> basic service (i.e. a simple revocation status request), some
> combination
> may be fine, but not sufficient for additional services (supported
> through
> extensions). So we would have to anticipate the needs for these
> extensions.
>
> In order to make sure we do not miss anything, a study should be
> done, at
> least for the three services that we are attempting to support, to
> explain
> and identify which combinations of these parameters are needed and
> thus make
> sense."
>
> Would you have an answer ?
>
>
> I agree with this, although in government and academic circles (at least),
> the words "a study should be done" often imply a delay of a year or longer
> before anyone hears an answer. I hope that this is not what you have in
> mind here and that, instead, this "study" could be completed by 2 or 3
> people at the San Diego meeting after they've ordered their lunch and
> before they've finished eating it. It's just a matter of figuring out
> which combinations make sense for each service and writing it down in the
> spec as a set of MUSTs and SHOULDs. This should not be difficult.
>
> >> This makes four oppositions, if I count correctly and - maybe -
> eight
> >> in favor: this is NOT a rough consensus.
> >
> > Actually, my impression is that in IETF any majority can be
> considered
> > "rough consensus" if an issue has dragged on long enough and a
> > specification needs to progress. Certainly, a 2/3 majority would
> be
> > considered "rough consensus" in many circles (even outside IETF!).
> While
> > it is likely the case that not all the opinions are in yet, at the
> moment
> > I doubt that many would claim that this vote was "too close to
> call".
>
> The fact is that we have no consensus on any ASN.1 syntax change
> today.
> Simon might be right when saying: "The bottom line is, lets stick
> with
> RFC2560, and move on with it", ... unless arguments are given to
> explain the
> use of every extension and reduce the number of cases of practical
> combinations.
>
>
> Perhaps we have no "consensus" on a specific ASN.1 syntax change, but all
> I'm claiming is that (at the moment) there appears to be "rough consensus"
> on the need for (or utility of) a change. I agree that we shouldn't just
> add lots of new options for the fun of it; we should consider carefully
> what is really needed and specify the mandatory combinations. Again, I
> think that progress can be made on this front fairly quickly.
>
> Carlisle.
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12258 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 08:14:35 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <W5KZLWB9>; Tue, 28 Nov 2000 11:16:17 -0500
Message-ID: <DD62792EA182FF4E99C2FBC07E3053BD053E9F@sottmxs09.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org, Michael Myers <MMyers@verisign.com>
Subject: RE: OCSP identifiers
Date: Tue, 28 Nov 2000 11:15:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05956.7B135D20"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C05956.7B135D20
Content-Type: text/plain
Hi Denis,
> ----------
> From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net]
> Sent: Tuesday, November 28, 2000 10:32 AM
> To: Carlisle Adams
> Cc: ietf-pkix@imc.org; Michael Myers
> Subject: Re: OCSP identifiers
>
> Carlisle,
>
> I am clearly opposed to the current OCSP v2 proposal, I am not opposed in
> principle to extensions, ... IF a rational is provided for these
> extensions
> AND we care for OCSCP v1 backward compatibility. In an E-mail posted to
> Mike
> this morning (Paris time), I raised a point raised much earlier, which
> remains to be answered:
>
> "Besides the ASN.1, explanations would need to be given to tell which
> combinations of these parameters make sense. The problem is that for the
> basic service (i.e. a simple revocation status request), some combination
> may be fine, but not sufficient for additional services (supported through
> extensions). So we would have to anticipate the needs for these
> extensions.
>
> In order to make sure we do not miss anything, a study should be done, at
> least for the three services that we are attempting to support, to explain
> and identify which combinations of these parameters are needed and thus
> make
> sense."
>
> Would you have an answer ?
I agree with this, although in government and academic circles (at least),
the words "a study should be done" often imply a delay of a year or longer
before anyone hears an answer. I hope that this is not what you have in
mind here and that, instead, this "study" could be completed by 2 or 3
people at the San Diego meeting after they've ordered their lunch and before
they've finished eating it. It's just a matter of figuring out which
combinations make sense for each service and writing it down in the spec as
a set of MUSTs and SHOULDs. This should not be difficult.
> >> This makes four oppositions, if I count correctly and - maybe - eight
> >> in favor: this is NOT a rough consensus.
> >
> > Actually, my impression is that in IETF any majority can be considered
> > "rough consensus" if an issue has dragged on long enough and a
> > specification needs to progress. Certainly, a 2/3 majority would be
> > considered "rough consensus" in many circles (even outside IETF!).
> While
> > it is likely the case that not all the opinions are in yet, at the
> moment
> > I doubt that many would claim that this vote was "too close to call".
>
> The fact is that we have no consensus on any ASN.1 syntax change today.
> Simon might be right when saying: "The bottom line is, lets stick with
> RFC2560, and move on with it", ... unless arguments are given to explain
> the
> use of every extension and reduce the number of cases of practical
> combinations.
Perhaps we have no "consensus" on a specific ASN.1 syntax change, but all
I'm claiming is that (at the moment) there appears to be "rough consensus"
on the need for (or utility of) a change. I agree that we shouldn't just
add lots of new options for the fun of it; we should consider carefully what
is really needed and specify the mandatory combinations. Again, I think
that progress can be made on this front fairly quickly.
Carlisle.
------_=_NextPart_001_01C05956.7B135D20
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: OCSP identifiers</TITLE>
</HEAD>
<BODY>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Denis,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Denis =
Pinkas[SMTP:Denis.Pinkas@bull.net]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Tuesday, November 28, 2000 10:32 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">ietf-pkix@imc.org; Michael Myers</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: OCSP identifiers</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle,</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">I am clearly opposed to the current =
OCSP v2 proposal, I am not opposed in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">principle to extensions, ... IF a =
rational is provided for these extensions</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">AND we care for OCSCP v1 backward =
compatibility. In an E-mail posted to Mike</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this morning (Paris time), I raised a =
point raised much earlier, which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">remains to be answered:</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">"Besides the ASN.1, explanations =
would need to be given to tell which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">combinations of these parameters make =
sense. The problem is that for the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">basic service (i.e. a simple =
revocation status request), some combination</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">may be fine, but not sufficient for =
additional services (supported through</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">extensions). So we would have to =
anticipate the needs for these extensions. </FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">In order to make sure we do not miss =
anything, a study should be done, at</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">least for the three services that we =
are attempting to support, to explain</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and identify which combinations of =
these parameters are needed and thus make</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sense." </FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Would you have an answer ?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman"> </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I agree =
with this, although in government and academic circles (at least), the =
words "a study should be done" often imply a delay of a year =
or longer before anyone hears an answer. I hope that this is not =
what you have in mind here and that, instead, this "study" =
could be completed by 2 or 3 people at the San Diego meeting after =
they've ordered their lunch and before they've finished eating =
it. It's just a matter of figuring out which combinations make =
sense for each service and writing it down in the spec as a set of =
MUSTs and SHOULDs. This should not be difficult.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">>> This makes four oppositions, =
if I count correctly and - maybe - eight</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">>> in favor: this is NOT a =
rough consensus.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Actually, my impression is that =
in IETF any majority can be considered</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> "rough consensus" if =
an issue has dragged on long enough and a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> specification needs to =
progress. Certainly, a 2/3 majority would be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> considered "rough =
consensus" in many circles (even outside IETF!). =
While</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> it is likely the case that not =
all the opinions are in yet, at the moment</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> I doubt that many would claim =
that this vote was "too close to call".</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">The fact is that we have no consensus =
on any ASN.1 syntax change today.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Simon might be right when saying: =
"The bottom line is, lets stick with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">RFC2560, and move on with it", =
... unless arguments are given to explain the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">use of every extension and reduce the =
number of cases of practical</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">combinations.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman"> </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Perhaps we have no "consensus" on a specific =
ASN.1 syntax change, but all I'm claiming is that (at the moment) there =
appears to be "rough consensus" on the need for (or utility =
of) a change. I agree that we shouldn't just add lots of new =
options for the fun of it; we should consider carefully what is really =
needed and specify the mandatory combinations. Again, I think =
that progress can be made on this front fairly quickly.</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C05956.7B135D20--
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11777 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 08:08:06 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA99216 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 11:08:51 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id LAA74070 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 11:07:57 -0500
Importance: Normal
Subject: Re: I-D ACTION:draft-ietf-pkix-technr-02.txt
To: ietf-pkix@imc.org
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF9D89EBC4.29BB726D-ON852569A5.005436D7@somers.hqregion.ibm.com>
From: "Tom Gindin" <tgindin@us.ibm.com>
Date: Tue, 28 Nov 2000 11:09:15 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Build V506_11152000 |November 15, 2000) at 11/28/2000 11:09:30 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
I have posted this draft with the intention of publishing it as an
Informational RFC. The WG chairs are aware of this intent, and they
approve of my proposing its publication.
Tom Gindin
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06037 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 07:31:45 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA09734; Tue, 28 Nov 2000 16:39:12 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA15812; Tue, 28 Nov 2000 16:32:30 +0100
Message-ID: <3A23D00F.1D522DE2@bull.net>
Date: Tue, 28 Nov 2000 16:32:31 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Carlisle Adams <carlisle.adams@entrust.com>
CC: ietf-pkix@imc.org, Michael Myers <MMyers@verisign.com>
Subject: Re: OCSP identifiers
References: <DD62792EA182FF4E99C2FBC07E3053BD053E9D@sottmxs09.entrust.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA06041
Carlisle,
> Hi Denis,
>
> ----------
> From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net]
> Sent: Tuesday, November 28, 2000 8:17 AM
> To: Michael Myers
> Cc: ietf-pkix@imc.org
> Subject: Re: OCSP identifiers
>
> > I was not claiming a consensus on the fundamental need to amend RFC
> > 2560's certificate identification syntax. But since you brought it up, it
> > would be useful to tally across the "Re: OCSP identifiers" thread. I've
> > done so.
> > Among those who spoke on-list regarding OCSPv2's proposal to amend
> > RFC 2560's certID syntax, PKIX has:
> >
> > 9 in favor
> > 2 opposed
> >
> > Below is the précis underlying that count.
> >
> > Mike
> >
> > In favor
> > --------
> > Michael Myers
> > Carlisle Adamas
> > Stephen Farrell
> > Rich Ankney
> > Denis Pinkas
> > (noting that Denis proposes an alternative means
> > of expanding RFC 2560's certID.)
>
> !?!?!? Please, Mike, count me on the OPPOSED side.
>
>
> The vote here (as Mike mentions above) was on "the fundamental need to
> amend RFC 2560's certificate identification syntax". Why in the world
> would you propose a means to extend the 2560 syntax to accommodate other
> means of identification if you are "OPPOSED" to the idea that the syntax
> needs amending? Were you deliberately trying to confuse us all? :-)
Sorry ... I misread the argument.
> It seemed quite clear to me that you agreed that additional means of
> identification would be valuable (i.e., that the current syntax was
> insufficient for some environments), but were just trying to ensure that
> this was done in a backward compatible way (as much as possible). Thus, I
> was not at all surprised to see Mike put you in the "favor" column, and am
> quite surprised to see you asking to be put in the "opposed" column.
> Anyway, thanks for the clarification!
I am clearly opposed to the current OCSP v2 proposal, I am not opposed in
principle to extensions, ... IF a rational is provided for these extensions
AND we care for OCSCP v1 backward compatibility. In an E-mail posted to Mike
this morning (Paris time), I raised a point raised much earlier, which
remains to be answered:
"Besides the ASN.1, explanations would need to be given to tell which
combinations of these parameters make sense. The problem is that for the
basic service (i.e. a simple revocation status request), some combination
may be fine, but not sufficient for additional services (supported through
extensions). So we would have to anticipate the needs for these extensions.
In order to make sure we do not miss anything, a study should be done, at
least for the three services that we are attempting to support, to explain
and identify which combinations of these parameters are needed and thus make
sense."
Would you have an answer ?
>> This makes four oppositions, if I count correctly and - maybe - eight
>> in favor: this is NOT a rough consensus.
>
> Actually, my impression is that in IETF any majority can be considered
> "rough consensus" if an issue has dragged on long enough and a
> specification needs to progress. Certainly, a 2/3 majority would be
> considered "rough consensus" in many circles (even outside IETF!). While
> it is likely the case that not all the opinions are in yet, at the moment
> I doubt that many would claim that this vote was "too close to call".
The fact is that we have no consensus on any ASN.1 syntax change today.
Simon might be right when saying: "The bottom line is, lets stick with
RFC2560, and move on with it", ... unless arguments are given to explain the
use of every extension and reduce the number of cases of practical
combinations.
Regards,
Denis
> Carlisle.
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04280 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 07:12:48 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <W5KZLVZL>; Tue, 28 Nov 2000 10:14:27 -0500
Message-ID: <DD62792EA182FF4E99C2FBC07E3053BD053E9D@sottmxs09.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org, Michael Myers <MMyers@verisign.com>
Subject: RE: OCSP identifiers
Date: Tue, 28 Nov 2000 10:14:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0594D.D7D617E0"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C0594D.D7D617E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Denis,
> ----------
> From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net]
> Sent: Tuesday, November 28, 2000 8:17 AM
> To: Michael Myers
> Cc: ietf-pkix@imc.org
> Subject: Re: OCSP identifiers
>=20
> > I was not claiming a consensus on the fundamental need to amend RFC
> 2560's
> > certificate identification syntax. But since you brought it up, it
> would be
> > useful to tally across the "Re: OCSP identifiers" thread. I've =
done so.
> > Among those who spoke on-list regarding OCSPv2's proposal to amend =
RFC
> > 2560's certID syntax, PKIX has:
> >=20
> > 9 in favor
> > 2 opposed
> >=20
> > Below is the pr=E9cis underlying that count.
> >=20
> > Mike
> >=20
> > In favor
> > --------
> > Michael Myers
> > Carlisle Adamas
> > Stephen Farrell
> > Rich Ankney
> > Denis Pinkas
> > (noting that Denis proposes an alternative means
> > of expanding RFC 2560's certID.)
>=20
> !?!?!? Please, Mike, count me on the OPPOSED side.
=20
The vote here (as Mike mentions above) was on "the fundamental need to =
amend
RFC 2560's certificate identification syntax". Why in the world would =
you
propose a means to extend the 2560 syntax to accommodate other means of
identification if you are "OPPOSED" to the idea that the syntax needs
amending? Were you deliberately trying to confuse us all? :-)
It seemed quite clear to me that you agreed that additional means of
identification would be valuable (i.e., that the current syntax was
insufficient for some environments), but were just trying to ensure =
that
this was done in a backward compatible way (as much as possible). =
Thus, I
was not at all surprised to see Mike put you in the "favor" column, and =
am
quite surprised to see you asking to be put in the "opposed" column.
Anyway, thanks for the clarification!
> This makes four oppositions, if I count correctly and - maybe - eight =
in
> favor: this is NOT a rough consensus.
=20
Actually, my impression is that in IETF any majority can be considered
"rough consensus" if an issue has dragged on long enough and a =
specification
needs to progress. Certainly, a 2/3 majority would be considered =
"rough
consensus" in many circles (even outside IETF!). While it is likely =
the
case that not all the opinions are in yet, at the moment I doubt that =
many
would claim that this vote was "too close to call".
Carlisle.
------_=_NextPart_001_01C0594D.D7D617E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: OCSP identifiers</TITLE>
</HEAD>
<BODY>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Denis,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Denis =
Pinkas[SMTP:Denis.Pinkas@bull.net]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Tuesday, November 28, 2000 8:17 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Michael =
Myers</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">ietf-pkix@imc.org</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: OCSP identifiers</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">> I was not claiming a consensus on =
the fundamental need to amend RFC 2560's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> certificate identification =
syntax. But since you brought it up, it would be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> useful to tally across the =
"Re: OCSP identifiers" thread. I've done so.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Among those who spoke on-list =
regarding OCSPv2's proposal to amend RFC</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> 2560's certID syntax, PKIX =
has:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> 9 in favor</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> 2 opposed</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Below is the pr=E9cis underlying =
that count.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Mike</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> In favor</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> --------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Michael Myers</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Carlisle Adamas</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Stephen Farrell</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Rich Ankney</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> Denis Pinkas</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> (noting that =
Denis proposes an alternative means</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">> of =
expanding RFC 2560's certID.)</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">!?!?!? Please, Mike, count me on the =
OPPOSED side.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman"> </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The vote =
here (as Mike mentions above) was on "the fundamental need to =
amend RFC 2560's certificate identification syntax". Why in =
the world would you propose a means to extend the 2560 syntax to =
accommodate other means of identification if you are =
"OPPOSED" to the idea that the syntax needs amending? =
Were you deliberately trying to confuse us all? :-)</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">It seemed =
quite clear to me that you agreed that additional means of =
identification would be valuable (i.e., that the current syntax was =
insufficient for some environments), but were just trying to ensure =
that this was done in a backward compatible way (as much as =
possible). Thus, I was not at all surprised to see Mike put you =
in the "favor" column, and am quite surprised to see you =
asking to be put in the "opposed" column. Anyway, =
thanks for the clarification!</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">This makes four oppositions, if I =
count correctly and - maybe - eight in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">favor: this is NOT a rough =
consensus.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman"> </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Actually, =
my impression is that in IETF any majority can be considered =
"rough consensus" if an issue has dragged on long enough and =
a specification needs to progress. Certainly, a 2/3 majority =
would be considered "rough consensus" in many circles (even =
outside IETF!). While it is likely the case that not all the =
opinions are in yet, at the moment I doubt that many would claim that =
this vote was "too close to call".</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C0594D.D7D617E0--
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02430 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 06:29:42 -0800 (PST)
Received: from certplus.com ([192.168.212.160]) by certplus.com (8.8.7/8.8.7) with ESMTP id PAA07882 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 15:35:28 +0100
Message-ID: <3A23C186.5494CFA8@certplus.com>
Date: Tue, 28 Nov 2000 15:30:30 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: OIDs as URIs
References: <NDBBJJNFOMNNKFDPLCDJIEGMCEAA.Karl.Scheibelhofer@iaik.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Karl Scheibelhofer wrote:
> > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > Karl,
> > > > From: Ambarish Malpani [mailto:ambarish@valicert.com]
> > > > Hi Karl,
> > > > Any issue with encoding oids as:
> > > > oid://0.4.0.1733.1.4.1
> > > >
> > > this URL is not dereferencable.
> >
> > This is not needed, as a way to express an OID.
>
> yes, i know that it is not absolutely required to work.
The URN working group is working on ways to dereference URN/URI that could be
easily applied to this.
In fact, if they get implemented, then the description in
draft-mealling-oid-urn-02.txt becomes instantly dereferencable; with only a need
for a registration of the type.
The question is to know what you will get when you dereference it.
> > > it is not human readable.
> >
> > This is not needed either.
>
> for use in XML i would heavily recommend that it is human readable. as i
> already stated in another message, this was a design goal for XML: "XML
> documents should be human-legible and reasonably clear." i think this
> advantage should not be underestimated.
The problem here is that you can get the text form from the numbers, but it's
more difficult to get the number form from the text and to ensure there is only
one representation of the text form.
What must be registered is the number, not the text.
I think a BER/DER like solution, where the string _could_ be represented with
the text, at places where it's not required to have a unique representation
(ouside of signed content) can be used.
> > > thus, i would say
> > > it is not suitable for a textual encoding like e.g. XML. there is no
> > > advantage of your suggestion over RFC 3001. if you are satisfied with
> > > numbers only the current RFC 3001 is exactly what you mean.
> >
> > RFC 3001 is quite new: A URN Namespace of Object Identifiers. M. Mealling.
> > November 2000. (Format: TXT=7459 bytes) (Status: INFORMATIONAL)
> >
> > I went on the offical web server from the IETF
> > (http://www.ietf.org/rfc.html) making a query for and it is yet not there.
> > The official URL http://www.ietf.org/rfc/rfc3001.txt does not respond
> > either. Would you be able to tell us where to find that document ?
>
> i found it, with a link to it, via the rfc-editor page. i cannot connect to
> it at the moment.
Found a link to it as an expired draft ?!
http://www.ietf.org/internet-drafts/draft-mealling-oid-urn-02.txt
I assume this version is the same as the version submitted to the RFC editor,
and is keeped there until the RFC is available.
> > However, I observed that the status of this document is INFORMATIONAL,
> > instead of PROPOSED STANDARD (or STANDARD).
>
> yes, i know. but it's worth to be considered, since it is very similar to
> the URN approach the we discussed.
Indeed, this _is_ the urn approach that was discussed :
draft-mealling-oid-urn-02.txt :
3. Examples
The following examples are taken from the example OIDs from the
Introduction:
urn:oid:1.3.6.1
urn:oid:1.3.6.1.4.1
urn:oid:1.3.6.1.2.1.27
URN:OID:0.9.2342.19200300.100.4
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27100 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 05:45:07 -0800 (PST)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A72C54B0086; Tue, 28 Nov 2000 14:46:20 +0100
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0 17/November/2000); Tue, 28 Nov 2000 14:44:05 +0100
From: "Karl Scheibelhofer" <Karl.Scheibelhofer@iaik.at>
To: "Denis Pinkas" <Denis.Pinkas@bull.net>
Cc: "IETF PKIX Mailing List" <ietf-pkix@imc.org>
Subject: RE: OIDs as URIs
Date: Tue, 28 Nov 2000 14:44:05 +0100
Message-ID: <NDBBJJNFOMNNKFDPLCDJIEGMCEAA.Karl.Scheibelhofer@iaik.at>
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 IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3A239BC2.9ED3C5FB@bull.net>
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Tuesday, November 28, 2000 12:49 PM
> To: Karl Scheibelhofer
> Cc: IETF PKIX Mailing List
> Subject: Re: OIDs as URIs
>
>
> Karl,
>
> > > -----Original Message-----
> > > From: Ambarish Malpani [mailto:ambarish@valicert.com]
> > > Sent: Monday, November 27, 2000 4:46 PM
> > > To: 'Karl Scheibelhofer'; IETF PKIX Mailing List
> > > Subject: RE: OIDs as URIs
> > >
> > > Hi Karl,
> > > Any issue with encoding oids as:
> > >
> > > oid://0.4.0.1733.1.4.1
> > >
> > > (Kind of like your second suggestion, without the extra text).
> >
> > this URL is not dereferencable.
>
> This is not needed, as a way to express an OID.
yes, i know that it is not absolutely required to work.
>
> > it is not human readable.
>
> This is not needed either.
for use in XML i would heavily recommend that it is human readable. as i
already stated in another message, this was a design goal for XML: "XML
documents should be human-legible and reasonably clear." i think this
advantage should not be underestimated.
>
> > thus, i would say
> > it is not suitable for a textual encoding like e.g. XML. there is no
> > advantage of your suggestion over RFC 3001. if you are satisfied with
> > numbers only the current RFC 3001 is exactly what you mean.
>
> RFC 3001 is quite new: A URN Namespace of Object Identifiers. M. Mealling.
> November 2000. (Format: TXT=7459 bytes) (Status: INFORMATIONAL)
>
> I went on the offical web server from the IETF
> (http://www.ietf.org/rfc.html) making a query for and it is yet not there.
> The official URL http://www.ietf.org/rfc/rfc3001.txt does not respond
> either. Would you be able to tell us where to find that document ?
i found it, with a link to it, via the rfc-editor page. i cannot connect to
it at the moment.
>
> However, I observed that the status of this document is INFORMATIONAL,
> instead of PROPOSED STANDARD (or STANDARD).
yes, i know. but it's worth to be considered, since it is very similar to
the URN approach the we discussed.
regards
Karl Scheibelhofer
--
Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25533 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 05:16:26 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA68736; Tue, 28 Nov 2000 14:23:59 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA17458; Tue, 28 Nov 2000 14:17:17 +0100
Message-ID: <3A23B05E.4A13F8BA@bull.net>
Date: Tue, 28 Nov 2000 14:17:18 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <MMyers@verisign.com>
CC: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <2F3EC696EAEED311BB2D009027C3F4F401C5BA0D@vhqpostal.verisign.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA25534
Michael,
> Ambarish,
>
> In the context of my response to Denis, you asked today:
>
> > Did I miss some mails? Not sure I saw any consensus on
> > changing the way of identifying the certificate at all.
>
> I was speaking to Denis about consensus on his proposed syntax for alternate
> certificate identification. His proposal conflicts in technical detail with
> the OCSPv2 authors' proposal addressing the same need. This is something
> Denis, I and my co-authors will work through in San Diego.
>
> I was not claiming a consensus on the fundamental need to amend RFC 2560's
> certificate identification syntax. But since you brought it up, it would be
> useful to tally across the "Re: OCSP identifiers" thread. I've done so.
> Among those who spoke on-list regarding OCSPv2's proposal to amend RFC
> 2560's certID syntax, PKIX has:
>
> 9 in favor
> 2 opposed
>
> Below is the précis underlying that count.
>
> Mike
>
> In favor
> --------
> Michael Myers
> Carlisle Adamas
> Stephen Farrell
> Rich Ankney
> Denis Pinkas
> (noting that Denis proposes an alternative means
> of expanding RFC 2560's certID.)
!?!?!? Please, Mike, count me on the OPPOSED side.
This makes four oppositions, if I count correctly and - maybe - eight in
favor: this is NOT a rough consensus.
Denis
> Margus Freudenthal
> (who on 11/17 wrote in part "I would support
> including the certificate hash option as well.")
> Peter Gutman
> (who on 11/16 wrote in part "I would really like
> to see this [>(Serial#, IssuerPKHash, IssuerDNHash]
> fixed [since], as I pointed out in my earlier
> message you can do something with the issuer name
> and serial number . . . [because] you can't do
> anything when one component is in a hashed form
> and the other one isn't.")
> Michael Ströder
> (who on 11/16 in response to Rich Salz's observation
> "I always thought {Issuer-DN, Subject-DN, Serial#}
> was relatively short and to the point and unique."
> said "you're damn right! But this would be too
> easy... (Sigh! ;-)")
> Rich Salz
> (see above)
>
> Opposed
> -------
> Ambarish Malpani
> Paul Hoffman
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA19588 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 03:48:19 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA57928; Tue, 28 Nov 2000 12:55:52 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA11634; Tue, 28 Nov 2000 12:49:22 +0100
Message-ID: <3A239BC2.9ED3C5FB@bull.net>
Date: Tue, 28 Nov 2000 12:49:22 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at>
CC: IETF PKIX Mailing List <ietf-pkix@imc.org>
Subject: Re: OIDs as URIs
References: <NDBBJJNFOMNNKFDPLCDJIEGHCEAA.Karl.Scheibelhofer@iaik.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Karl,
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:ambarish@valicert.com]
> > Sent: Monday, November 27, 2000 4:46 PM
> > To: 'Karl Scheibelhofer'; IETF PKIX Mailing List
> > Subject: RE: OIDs as URIs
> >
> > Hi Karl,
> > Any issue with encoding oids as:
> >
> > oid://0.4.0.1733.1.4.1
> >
> > (Kind of like your second suggestion, without the extra text).
>
> this URL is not dereferencable.
This is not needed, as a way to express an OID.
> it is not human readable.
This is not needed either.
> thus, i would say
> it is not suitable for a textual encoding like e.g. XML. there is no
> advantage of your suggestion over RFC 3001. if you are satisfied with
> numbers only the current RFC 3001 is exactly what you mean.
RFC 3001 is quite new: A URN Namespace of Object Identifiers. M. Mealling.
November 2000. (Format: TXT=7459 bytes) (Status: INFORMATIONAL)
I went on the offical web server from the IETF
(http://www.ietf.org/rfc.html) making a query for and it is yet not there.
The official URL http://www.ietf.org/rfc/rfc3001.txt does not respond
either. Would you be able to tell us where to find that document ?
However, I observed that the status of this document is INFORMATIONAL,
instead of PROPOSED STANDARD (or STANDARD).
Regards,
Denis
> regards
>
> Karl Scheibelhofer
>
> --
>
> Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
> Institute for Applied Information Processing and Communications (IAIK)
> at Technical University of Graz, Austria, http://www.iaik.at
> Phone: (+43) (316) 873-5540
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14363 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 02:59:59 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04687; Tue, 28 Nov 2000 06:01:22 -0500 (EST)
Message-Id: <200011281101.GAA04687@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-ocspv2-01.txt
Date: Tue, 28 Nov 2000 06:01:21 -0500
Sender: nsyracus@cnri.reston.va.us
--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 : Online Certificate Status Protocol, version 2
Author(s) : M. Myers, R. Ankney, C. Adams
Filename : draft-ietf-pkix-ocspv2-01.txt
Pages : 20
Date : 27-Nov-00
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.
An overview of the protocol is provided in section 2. Functional
requirements are specified in section 4. Details of the protocol are
in section 5. We cover security issues with the protocol in section
6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
syntactic elements and appendix C specifies the mime types for the
messages.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspv2-01.txt
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-ocspv2-01.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:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-ocspv2-01.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="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001127133247.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ocspv2-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-ocspv2-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001127133247.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14286 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 02:59:53 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04629; Tue, 28 Nov 2000 06:01:16 -0500 (EST)
Message-Id: <200011281101.GAA04629@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-technr-02.txt
Date: Tue, 28 Nov 2000 06:01:16 -0500
Sender: nsyracus@cnri.reston.va.us
--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 Technical
Requirements for a non-Repudiation Service
Author(s) : T. Gindin
Filename : draft-ietf-pkix-technr-02.txt
Pages : 7
Date : 27-Nov-00
This document describes those features of a service which processes
signed documents which must be present in order for that service to
constitute a 'technical non-repudiation' service. A technical
non-repudiation service must permit an independent verifier to
determine whether a given signature was applied to a given data
object by the private key associated with a given valid certificate,
at a time later than the signature. The features of a technical non-
repudiation service are expected to be necessary for a full non-
repudiation service, although they may not be sufficient.
This document is intended to clarify the definition of the
'non-repudiation' service in RFC 2459. It should thus serve as a
guide to when the nonRepudiation bit of the keyUsage extension should
be set and to when a Certificate Authority is required to archive
CRL's.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-technr-02.txt
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-technr-02.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:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-technr-02.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="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001127133237.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-technr-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-technr-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001127133237.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12167 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 02:35:49 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA68782; Tue, 28 Nov 2000 11:43:22 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA12992; Tue, 28 Nov 2000 11:36:37 +0100
Message-ID: <3A238AB6.F673C329@bull.net>
Date: Tue, 28 Nov 2000 11:36:38 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <MMyers@verisign.com>
CC: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <2F3EC696EAEED311BB2D009027C3F4F401C5BA0C@vhqpostal.verisign.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA12171
Michael,
I pick up this message to tell you that:
> Dave,
>
> > On Monday, November 20, 2000 8:58 AM you said in part:
> >
> > CRL-driven [OCSP] responders are a requirement in my
> > environment, and OCSP products which cannot be fed
> > by CRLs will not be purchased.
>
> When I said that "OCSP isn't and should't be tied to CRLs", I was observing
> that CRLs are one means for a CA to store the data needed by an OCSP
> responder. Alternatives exist; these include direct database lookup or an
> LDAP-based query of a directory. We must preserve that flexibility. RFC
> 2560 enables use of CRLs in any variation. There's neither intent nor
> proposal to remove that support.
1° I agree with your text. The implication is that any basic status
revocation response should be built using only information that is present
in "fresh" CRLs. This may be self-evident, but it is better to say it.
2° I am still awaiting a response from you on my previous E-mails. Since you
might not remember, here is now (for the third time), the questions that I
raised:
========================================================================
E-mail from November, 15:
Mike,
A few, but important comments on this E-mail sent last week.
> Russ, thanks for getting this debate kicked off. After all the work various
> of us have put into this issue, I was beginning to think no one cared.
>
> All, as to the debate:
>
> Let's hear from everybody before we make a decision.
> ----------------------------------------------------
> Thanks to all who have read the IDs and provided comments (especially Denis
> Pinkas). But since active WG members have taken time out of their busy
> schedules to improve the IDs, I think it only fair that final judgement be
> witheld until those contributions are folded into a revised version for our
> consideration in San Diego. At that time it might be more appropriate to
> decide between the two.
>
> It's DPV vs. SCVP
> -----------------
> OCSP-X has expired; DPV and DPD replace that initial work. The requirement
> we're all most concerned about is delegated path validation (although
> delegated path discovery has it's use). So it really comes down to DPV+DPD
> vs. SCVP since OCSP is already RFC 2560. DPV is little more than an OID and
> a corresponding semantic; it simply puts more meat behind 2560's notion of
> "good".
I disagree with this last statement. Extensions allows to request new
services. The request for each every new service may fail or succeed. This
means that each extension will have to carry the result of the request for
the new service. This also means that the current status will only carry the
response to a *status revocation request*, but will not carry any additional
meaning. "Good" is not the appropriate term to be used: "not revoked" is the
right term and should be used instead, when we revised OCSP.
> DPD is only a bit more along these same lines of design.
>
> They're going to do it anyway.
> ------------------------------
> DPV and DPD are nothing more than proposed standard extensions to the
> already existing extension hooks in 2560. Given the availablility of those
> hooks, there's nothing to stop any environment from doing precisely this, if
> only to establish a closed system-level solution. Given that, it's better
> that we take responsible action to promote Internet interoperability via a
> standard means of doing so in the event that such closed environments may
> someday find it useful to interoperate.
The real advantage to add DPV and DPD to OCSP is to be able to support both
a revocation status request and DPV or DPV+DPD in a single request. It
should however be noticed that a response to a status revocation request is
not mandatory since the server may well return a "revocation status unknown"
response, but still respond to a DPD (Delegated Path Discovery) for the
certificate.
========================================================================
E-mail from November, 16:
Michael,
My original text contains several arguments; many of them do have no direct
answer in your reply. Please, next time, use my original text to reply.
Nevertheless, see my responses embedded in you new text.
> Denis,
>
> Thanks for your in-depth review and comments on OCSPv2, both here and in
> your off-list communications. To my reading, you have four points:
>
> Replace "good" with "not revoked"
> ---------------------------------
> The last call for comments on the I-D that led to RFC2560 occurred roughly
> two years ago.
This is not an argument. The mis-use of "good", you currently make, is now
there to prove that there is a problem. Once again here is the text I
posted, on which you have not responded:
Extensions allows to request new services. The request for each every new
service may fail or succeed. This means that each extension will have to
carry the result of the request for the new service. This also means that
the current status will only carry the response to a *status revocation
request*, but will not carry any additional meaning. "Good" is not the
appropriate term to be used: "not revoked" is the right term and should be
used instead, when we revised OCSP.
> Replace "unknown" with "revocation status unknown"
> --------------------------------------------------
> See above.
The same.
> It should not be manadatory to implement revocation status.
> -----------------------------------------------------------
> RFC2560 asserts that servers SHALL implement revocation status. In other
> words, "shall be capable of" in order to ensure a minimum level of
> interoperability across the Internet. It does not however require
> deployment or activation of this functionality. Does this clarification
> satisfy your concern?
This is not what I said. Here is my original text:
" The real advantage to add DPV and DPD to OCSP is to be able to support
both a revocation status request and DPV or DPV+DPD in a single request.
It should however be noticed that a response to a status revocation request
is not mandatory since the server may well return a "revocation status
unknown" response, but still respond to a DPD (Delegated Path Discovery)
for the certificate."
Besides the exact wording, I would guess that we agree in principle on that
point.
(some text about CertId deleted)
It maybe the right time to mention that I have never be pleased by using:
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
instead of the issuer DN.
The argument given at this time was the following: since the server has some
private agreements with a CA he is working for, it knows their names and
then can compute the hash of that name. If the service that is requested is
only a path discovery, then the argument does not stand anymore, since the
server may have access to a large number of certificates which are
identified by their name, not their hash. Adding "issuer" to the list of
optional parameters would thus make sense.
Besides the ASN.1, explanations would need to be given to tell which
combinations of these parameters make sense. The problem is that for the
basic service (i.e. a simple revocation status request), some combination
may be fine, but not sufficient for additional services (supported through
extensions). So we would have to anticipate the needs for these extensions.
In order to make sure we do not miss anything, a study should be done, at
least for the three services that we are attempting to support, to explain
and identify which combinations of these parameters are needed and thus make
sense.
I hope these explanations help.
========================================================================
Regards,
Denis
> Mike
Received: from internet.across ([213.212.5.232]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA04157 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 01:18:10 -0800 (PST)
Received: FROM acrossw01.across BY internet.across ; Tue Nov 28 10:21:17 2000 +0100
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <XLAPNCAR>; Tue, 28 Nov 2000 10:17:20 +0100
Message-ID: <E5C2786F90B4D4119A200008C716F45D269FCD@acrossw01.acrosswireless.com>
From: Simon Tardell <simon.tardell@smarttrust.com>
To: "'Michael Myers'" <MMyers@verisign.com>, Ambarish Malpani <ambarish@valicert.com>, Denis Pinkas <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Tue, 28 Nov 2000 10:17:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA04158
Mike,
> Among those who spoke on-list regarding OCSPv2's proposal to amend RFC
> 2560's certID syntax, PKIX has:
>
> 9 in favor
> 2 opposed
>
> Below is the précis underlying that count.
count me to the opposition then.
I acknowledge the inelegance of CertID. If we would have done it from
scratch I would have proposed to do it slightly different, but now RFC2560
is there, and there is no fundamental problem with CertID I don't see enough
reason to change this. The changes that are proposed are rather major for
marginal or no gain, as I see it. Maybe it's ugly, but ain't broken.
The certHash option is a special problem. The CHOICE is a choice that the
client makes, not the responder, so if we allow certHash as a primary
identifier we will force responders to always have all certificates at hand
(or, rather, hashes thereof), even if we are only interested in revocation
information. Still, I recognize the need of, under some circumstances,
asking and answering the issuance question, so I propose that we make a
single request/response extension carrying the certHash for this purpose (in
a separate document). The observation here is that certHash should be a
qualification to the certificate identifier, rather than the certificate
identifier per se.
The pkCert and name options would more or less serve the same purpose, hence
I propose that they are put in (single) extensions, if they are needed at
all.
The bottom line is, lets stick with RFC2560, and move on with it.
Regards,
Simon.
Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
simon.tardell@smarttrust.com, http://www.smarttrust.com
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA14304 for <ietf-pkix@imc.org>; Tue, 28 Nov 2000 00:06:02 -0800 (PST)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A7BD1F3013C; Tue, 28 Nov 2000 09:07:25 +0100
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0 17/November/2000); Tue, 28 Nov 2000 09:06:05 +0100
From: "Karl Scheibelhofer" <Karl.Scheibelhofer@iaik.at>
To: "Paul Koning" <pkoning@ironstream.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: OIDs as URIs
Date: Tue, 28 Nov 2000 09:06:05 +0100
Message-ID: <NDBBJJNFOMNNKFDPLCDJIEGICEAA.Karl.Scheibelhofer@iaik.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <14882.41031.173963.755245@pkoning.ironstream.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> -----Original Message-----
> From: Paul Koning [mailto:pkoning@ironstream.com]
> Sent: Monday, November 27, 2000 6:56 PM
> To: Karl.Scheibelhofer@iaik.at
> Cc: ietf-pkix@imc.org
> Subject: Re: OIDs as URIs
>
>
> >>>>> "Karl" == Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at> writes:
>
> Karl> in the last ETSI ESI meeting we discussed how we could
> Karl> represent OID (ASN.1) as URIs. i proposed two schemes that seem
> Karl> reasonable. we would also like to hear other opinions. these
> Karl> two approaches are as follows:
>
> Karl> One encodes the OID as an URL and the other encodes it as an
> Karl> URN:
>
> Karl> · Encoding as URL: fix a base URL and append the OID in an
> Karl> appropriate format (human readable) e.g.,
> Karl>
> http://www.etsi.org/oid/itu-t(0)/identified-organization(4)/etsi(0
> )/electron
> Karl> ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
>
> It seems to me the text part is unnecessary clutter, the numbers alone
> would suffice.
for computers to read it - yes. for human readability - no.
>
> Then again, perhaps it's the other way around.
>
> What's the purpose of this? Why would you want to map an OID to a
> URI, and who/what would consume the resulting URI? The answer would
> affect the sort of encoding that makes sense, and for that matter
> whether the notion itself is at all useful.
it should be a syntactic valid URI and it should be human readable (as far
as possible and reasonable).
>
> Karl> The generated URL must be persistent! This means that the
> Karl> resulting URL must not be used to identify anything else than
> Karl> this OID. And this should be the case, at least as long as this
> Karl> URL is used to identify this OID.
>
> That's a problem of course. There is no naming authority for URIs
> that can enforce this, as there is for OIDs.
there is an naming authority for URNs (of their NID part exactly). it is
IANA. any URN is a valid URI.
there are also authorities for domain names. of course they can change their
owner. but if a company is sold, how about your OIDs? they also changed
their owner.
>
> Karl> + The owner
> Karl> of the OID can place a specification document at the place on
> Karl> his web server this URL refers to.
>
> But then the URL refers to a document. The document isn't the OID, so
> that contradicts the requirement you stated above.
good comment. i agree that it is perhaps inappropriate to use the URI as an
identifier for a "thing" other that the URI points to. perhaps we should
define something additionally like: append /specification to the URI to get
a specification; and only place a document to the actual location of the
URI, if the OID identifies that document.
regards
Karl Scheibelhofer
--
Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09527 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 23:52:20 -0800 (PST)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A48716E0138; Tue, 28 Nov 2000 08:53:43 +0100
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0 17/November/2000); Tue, 28 Nov 2000 08:52:23 +0100
From: "Karl Scheibelhofer" <Karl.Scheibelhofer@iaik.at>
To: "Ambarish Malpani" <ambarish@valicert.com>, "IETF PKIX Mailing List" <ietf-pkix@imc.org>
Subject: RE: OIDs as URIs
Date: Tue, 28 Nov 2000 08:52:23 +0100
Message-ID: <NDBBJJNFOMNNKFDPLCDJIEGHCEAA.Karl.Scheibelhofer@iaik.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <613B3C619C9AD4118C4E00B0D03E7C3E15307A@exchange.valicert.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> -----Original Message-----
> From: Ambarish Malpani [mailto:ambarish@valicert.com]
> Sent: Monday, November 27, 2000 4:46 PM
> To: 'Karl Scheibelhofer'; IETF PKIX Mailing List
> Subject: RE: OIDs as URIs
>
>
>
> Hi Karl,
> Any issue with encoding oids as:
>
> oid://0.4.0.1733.1.4.1
>
> (Kind of like your second suggestion, without the extra text).
this URL is not dereferencable. it is not human readable. thus, i would say
it is not suitable for a textual encoding like e.g. XML. there is no
advantage of your suggestion over RFC 3001. if you are satisfied with
numbers only the current RFC 3001 is exactly what you mean.
regards
Karl Scheibelhofer
--
Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03333 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 13:34:52 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA07167; Mon, 27 Nov 2000 13:29:32 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNFTMYN3>; Mon, 27 Nov 2000 13:33:32 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BA0C@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Mon, 27 Nov 2000 13:33:31 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Dave,
> On Monday, November 20, 2000 8:58 AM you said in part:
>
> CRL-driven [OCSP] responders are a requirement in my
> environment, and OCSP products which cannot be fed
> by CRLs will not be purchased.
When I said that "OCSP isn't and should't be tied to CRLs", I was observing
that CRLs are one means for a CA to store the data needed by an OCSP
responder. Alternatives exist; these include direct database lookup or an
LDAP-based query of a directory. We must preserve that flexibility. RFC
2560 enables use of CRLs in any variation. There's neither intent nor
proposal to remove that support.
Mike
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03137 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 13:32:18 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA24686; Mon, 27 Nov 2000 13:35:13 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNF224S9>; Mon, 27 Nov 2000 13:33:37 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5BA0D@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Ambarish Malpani <ambarish@valicert.com>, "'Michael Myers'" <MMyers@verisign.com>, Denis Pinkas <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Mon, 27 Nov 2000 13:33:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA03138
Ambarish,
In the context of my response to Denis, you asked today:
> Did I miss some mails? Not sure I saw any consensus on
> changing the way of identifying the certificate at all.
I was speaking to Denis about consensus on his proposed syntax for alternate
certificate identification. His proposal conflicts in technical detail with
the OCSPv2 authors' proposal addressing the same need. This is something
Denis, I and my co-authors will work through in San Diego.
I was not claiming a consensus on the fundamental need to amend RFC 2560's
certificate identification syntax. But since you brought it up, it would be
useful to tally across the "Re: OCSP identifiers" thread. I've done so.
Among those who spoke on-list regarding OCSPv2's proposal to amend RFC
2560's certID syntax, PKIX has:
9 in favor
2 opposed
Below is the précis underlying that count.
Mike
In favor
--------
Michael Myers
Carlisle Adamas
Stephen Farrell
Rich Ankney
Denis Pinkas
(noting that Denis proposes an alternative means
of expanding RFC 2560's certID.)
Margus Freudenthal
(who on 11/17 wrote in part "I would support
including the certificate hash option as well.")
Peter Gutman
(who on 11/16 wrote in part "I would really like
to see this [>(Serial#, IssuerPKHash, IssuerDNHash]
fixed [since], as I pointed out in my earlier
message you can do something with the issuer name
and serial number . . . [because] you can't do
anything when one component is in a hashed form
and the other one isn't.")
Michael Ströder
(who on 11/16 in response to Rich Salz's observation
"I always thought {Issuer-DN, Subject-DN, Serial#}
was relatively short and to the point and unique."
said "you're damn right! But this would be too
easy... (Sigh! ;-)")
Rich Salz
(see above)
Opposed
-------
Ambarish Malpani
Paul Hoffman
Received: from jlc.net (3ff83a80.dsl.flashcom.net [63.248.58.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18981 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 09:55:06 -0800 (PST)
Received: (from pkoning@localhost) by jlc.net (8.9.3/8.8.7) id MAA01474; Mon, 27 Nov 2000 12:56:23 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <14882.41031.173963.755245@pkoning.ironstream.com>
Date: Mon, 27 Nov 2000 12:56:23 -0500 (EST)
From: Paul Koning <pkoning@ironstream.com>
To: Karl.Scheibelhofer@iaik.at
Cc: ietf-pkix@imc.org
Subject: Re: OIDs as URIs
References: <NDBBJJNFOMNNKFDPLCDJAEFCCEAA.Karl.Scheibelhofer@iaik.at>
X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA18983
>>>>> "Karl" == Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at> writes:
Karl> in the last ETSI ESI meeting we discussed how we could
Karl> represent OID (ASN.1) as URIs. i proposed two schemes that seem
Karl> reasonable. we would also like to hear other opinions. these
Karl> two approaches are as follows:
Karl> One encodes the OID as an URL and the other encodes it as an
Karl> URN:
Karl> · Encoding as URL: fix a base URL and append the OID in an
Karl> appropriate format (human readable) e.g.,
Karl> http://www.etsi.org/oid/itu-t(0)/identified-organization(4)/etsi(0)/electron
Karl> ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
It seems to me the text part is unnecessary clutter, the numbers alone
would suffice.
Then again, perhaps it's the other way around.
What's the purpose of this? Why would you want to map an OID to a
URI, and who/what would consume the resulting URI? The answer would
affect the sort of encoding that makes sense, and for that matter
whether the notion itself is at all useful.
Karl> The generated URL must be persistent! This means that the
Karl> resulting URL must not be used to identify anything else than
Karl> this OID. And this should be the case, at least as long as this
Karl> URL is used to identify this OID.
That's a problem of course. There is no naming authority for URIs
that can enforce this, as there is for OIDs.
Karl> + The owner
Karl> of the OID can place a specification document at the place on
Karl> his web server this URL refers to.
But then the URL refers to a document. The document isn't the OID, so
that contradicts the requirement you stated above.
paul
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09226 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 07:47:14 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4O00701X8YPE@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 27 Nov 2000 07:48:34 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4O006O2X8YQV@ext-mail.valicert.com>; Mon, 27 Nov 2000 07:48:34 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <X3C2Y7WN>; Mon, 27 Nov 2000 07:46:07 -0800
Content-return: allowed
Date: Mon, 27 Nov 2000 07:46:06 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: OIDs as URIs
To: "'Karl Scheibelhofer'" <Karl.Scheibelhofer@iaik.at>, IETF PKIX Mailing List <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E15307A@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA09228
Hi Karl,
Any issue with encoding oids as:
oid://0.4.0.1733.1.4.1
(Kind of like your second suggestion, without the extra text).
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at]
> Sent: Friday, November 24, 2000 1:37 AM
> To: IETF PKIX Mailing List
> Subject: OIDs as URIs
>
>
> in the last ETSI ESI meeting we discussed how we could
> represent OID (ASN.1)
> as URIs. i proposed two schemes that seem reasonable. we
> would also like to
> hear other opinions.
> these two approaches are as follows:
>
> One encodes the OID as an URL and the other encodes it as an URN:
>
> · Encoding as URL:
> fix a base URL and append the OID in an appropriate format
> (human readable)
> e.g.,
> http://www.etsi.org/oid/itu-t(0)/identified-organization(4)/et
> si(0)/electron
> ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
> The generated URL must be persistent! This means that the
> resulting URL must
> not be used to identify anything else than this OID. And this
> should be the
> case, at least as long as this URL is used to identify this OID.
> Advantages and disadvantages of this approach that we are
> aware of by now,
> are as follows.
> Advantages:
> + Uses the widely know schema of URLs.
> + The owner of the OID can place a specification document
> at the place on
> his web server this URL refers to.
> + If there is no resource (e.g. a specification) at the
> given URL, then it
> is just a unique name like an OID is.
> + Every company can use its own base URL. Some people
> also mentioned the
> idea to use one base URL for all OIDs (e.g. http://www.w3.org/oid/,
> http://www.oid.int or http://www.iso.org/oid). This would
> have the advantage
> to have always the same base URL. The disadvantages would be:
> If the owners
> want to place a specification on the web server, the owning
> company would
> have to maintain web space for all OID owners (perhaps a redirection
> mechanism would solve this?). Additionally, if a company
> wants to use this
> base URL for internal (or even secret) purposes, it might not
> want to use
> the fixed base URL (perhaps, it could just use anyone, if it
> is just for
> internal use?)
> Disadvantages:
> - The company owning the domain name of the base URL must
> ensure that the
> base URL is persistent. It needs to be persistent as long as
> there is one or
> more URLs in use for identifying an OID using this base URL.
> Remind that the
> base URL includes the domain name and any additional directories.
> - If the URL is used just as a unique name without
> referring to any
> resource, it might confuse people.
>
> · Encoding as URN:
> register a NID (see RFC 2141 and RFC 2611) through IANA
> (http://www.iana.org)
> e.g., register "oid" as an NID, define NSS to identify an
> ASN.1 OID. This
> could look like
> urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic
> -signature-sta
> ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
> for instance.
> Advantages and disadvantages of this approach are:
> Advantages:
> + There is a central registration authority for NID.
> + This approach could serve for all OIDs automatically
> (e.g. if the
> registered NID would be "oid").
> + IANA guarantees that NID are registered only once.
> Disadvantages:
> - This mechanism of URNs with registered NIDs seems to be
> rarely used. Some
> people might reject it just because they are not familiar
> with that kind of
> URI.
> - There is no widely used and globally available
> mechanism to dereference an
> URN. Thus, it might not be possible to retrieve a
> specification with the
> given URN as seen with the approach using URLs.
> At first glance, the approach using a URN seems to have the
> advantage to
> guarantee uniqueness. But there is never a hundred percent
> guarantee for
> uniqueness of any data. It is simply impossible. No one can
> securely prevent
> me using any identifier the I want. In both approaches, the
> owner of the
> base URL or of the registered NID has to ensure some properties.
> Just consider the case in which a company is sold. If the
> succeeding owner
> decides to change the rules and reassign all previously used
> identifiers,
> the system does not work, no matter what scheme you use:
> URNs, URLs, or even
> OIDs. Any of these systems only works, if everyone stick to the rules.
>
>
> what do you think is the preferable approach?
>
>
> Karl Scheibelhofer
>
> --
>
> Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
> Institute for Applied Information Processing and Communications (IAIK)
> at Technical University of Graz, Austria, http://www.iaik.at
> Phone: (+43) (316) 873-5540
>
>
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07856 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 07:43:02 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4O00701X1XOU@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 27 Nov 2000 07:44:21 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4O006N8X1XQV@ext-mail.valicert.com>; Mon, 27 Nov 2000 07:44:21 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <X3C2Y7WD>; Mon, 27 Nov 2000 07:41:54 -0800
Content-return: allowed
Date: Mon, 27 Nov 2000 07:41:53 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: OCSP identifiers
To: "'Michael Myers'" <MMyers@verisign.com>, Denis Pinkas <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E153079@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Hi Mike,
Did I miss some mails? Not sure I saw any consensus on
changing the way of identifying the certificate at all.
Once again, if you assume that a client is responsible for
verifying the signature on a certificate, then requiring the
client to send over the hash of a CA's public key is not too
strenuous a requirement. While requiring clients to send over
the hash of the CA's DN was never a good idea, now that we have
it, I think we should just stick with it and proceed forward.
Having multiple possible ways of identifying a certificate will
only lead to more interop issues.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Michael Myers [mailto:MMyers@verisign.com]
> Sent: Friday, November 24, 2000 7:48 PM
> To: Denis Pinkas
> Cc: ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
>
> Denis,
>
> It's my understanding that IETF WGs are governed by the list,
> not the floor.
> I regret to note that the list to date does not appear to support your
> proposed alternative to OCSP certID syntax expansion. As I've said
> repeatedly, I have no other task but to record the WG's
> consensus. As lead
> author on OCSP, I have to at some point make a call in favor
> of forward
> progress. It appears to me that we do in fact have rough
> consensus on the
> certID syntax issue. You're of course free to bring this up
> on the floor in
> San Diego. That said, would you agree however that a floor
> consensus isn't
> necessarily a WG consensus, given that some in the WG may be
> constrained in
> their travel budgets?
>
> Mike
>
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01715 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 06:35:58 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA03151 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 09:12:48 -0500 (EST)
Message-Id: <200011271412.JAA03145@roadblock.missi.ncsc.mil>
Date: Mon, 27 Nov 2000 09:29:15 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: Holder
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: WeF40RdPJmpJePAWDeH8lw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
I don't believe that specifying a subset will result in any real
reduction in product/library development or testing complexity. But I
do believe that a recommendation will help Attribute Authorities
consider what they are trying to accomplish when using the product.
If a subset is to be specified, {2, 4, 9} is a good one.
I agree with:
> From: Steve Hanna <steve.hanna@sun.com>
>
> AC issuers SHOULD use only formats 2, 4, or 9. They MAY use other
> formats, as necessary. AC verifiers SHOULD support formats 2, 4, and
> 9 (subject to specific requirements and configuration). They MAY
> support other formats.
>
> Any objections? Agreement? General consensus?
>
> -Steve
Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA25758 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 05:31:50 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 011077713; Mon, 27 Nov 2000 08:32:53 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-13-230.bellatlantic.net [141.154.13.230]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id IAA03543; Mon, 27 Nov 2000 08:33:17 -0500
Message-ID: <3A226339.B7D9F781@caveosystems.com>
Date: Mon, 27 Nov 2000 08:35:53 -0500
From: Rich Salz <rsalz@caveosystems.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at>
CC: IETF PKIX Mailing List <ietf-pkix@imc.org>
Subject: Re: OIDs as URIs
References: <NDBBJJNFOMNNKFDPLCDJEEFPCEAA.Karl.Scheibelhofer@iaik.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
> > Why do we need to preserve the numerical values with the new
> > convention? The
> > digits attached to *unique* symbolics names don't do much.
> > ITU-T(0) - what is a purpose of preserving 0?
Because a machine can interpret a number without external information, unlike
a name.
Who is going to be the primary consumer of items in the "oid" URI -- computers
or people? Computers don't need the names, and their programmers would rather
have just the numbers. :)
/r$
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA17458 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 03:25:02 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA05209; Mon, 27 Nov 2000 12:26:18 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 27 Nov 2000 12:26:18 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id MAA06073; Mon, 27 Nov 2000 12:26:16 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA01503; Mon, 27 Nov 2000 12:26:16 +0100 (MET)
Date: Mon, 27 Nov 2000 12:26:16 +0100 (MET)
Message-Id: <200011271126.MAA01503@emeriau.edelweb.fr>
To: Karl.Scheibelhofer@iaik.at, ietf-pkix@imc.org, mzolotarev@baltimore.com
Subject: RE: OIDs as URIs
> >
> > in the last ETSI ESI meeting we discussed how we could
> > represent OID (ASN.1)
> > as URIs. i proposed two schemes that seem reasonable. we
> > would also like to
> > hear other opinions.
What about just making a reverse order OID in numeric form
and have some OID-rev.oid.int as a domain name. This
allows to make whetever delegation possible. It requires
of course, that the top level entities operate some
DNS servers.
The relavite parts of the URL could then be used in a fixed
global method to point to different types of descriptions.
http://1.4.1.1773.0.4.0.oid.int/specification.xml
where 4.0.oid.int would be delegated to ETSI.
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA17413 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 03:24:48 -0800 (PST)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A4C83B500BA; Mon, 27 Nov 2000 12:26:00 +0100
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0 17/November/2000); Mon, 27 Nov 2000 12:24:36 +0100
From: "Karl Scheibelhofer" <Karl.Scheibelhofer@iaik.at>
To: "Michael Zolotarev" <mzolotarev@baltimore.com>, "IETF PKIX Mailing List" <ietf-pkix@imc.org>
Subject: RE: OIDs as URIs
Date: Mon, 27 Nov 2000 12:24:36 +0100
Message-ID: <NDBBJJNFOMNNKFDPLCDJEEFPCEAA.Karl.Scheibelhofer@iaik.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <D44EACB40164D311BEF00090274EDCCADB7603@sydneymail1.jp.zergo.com.au>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> -----Original Message-----
> From: Michael Zolotarev [mailto:mzolotarev@baltimore.com]
> Sent: Monday, November 27, 2000 11:19 AM
> To: Karl Scheibelhofer; IETF PKIX Mailing List
> Subject: RE: OIDs as URIs
>
>
> Why do we need to preserve the numerical values with the new
> convention? The
> digits attached to *unique* symbolics names don't do much.
> ITU-T(0) - what is a purpose of preserving 0?
>
> Is it to simplify mapping from the 'new' style to conventional OIDs?
it allows easy mapping from one form to the other. i think this is enough to
keep this form. additionally, it might be required to allow OIDs without
names - just numbers. i think that the names are not mandatory with OIDs and
thus they are not always present.
regards
Karl Scheibelhofer
--
Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10428 for <ietf-pkix@imc.org>; Mon, 27 Nov 2000 02:19:34 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id UAA28629; Mon, 27 Nov 2000 20:27:58 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <X3JY7DMC>; Mon, 27 Nov 2000 21:18:55 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCADB7603@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at>, IETF PKIX Mailing List <ietf-pkix@imc.org>
Subject: RE: OIDs as URIs
Date: Mon, 27 Nov 2000 21:18:54 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA10435
Why do we need to preserve the numerical values with the new convention? The
digits attached to *unique* symbolics names don't do much.
ITU-T(0) - what is a purpose of preserving 0?
Is it to simplify mapping from the 'new' style to conventional OIDs?
> -----Original Message-----
> From: Karl Scheibelhofer [mailto:Karl.Scheibelhofer@iaik.at]
> Sent: Friday, 24 November 2000 19:37
> To: IETF PKIX Mailing List
> Subject: OIDs as URIs
>
>
> in the last ETSI ESI meeting we discussed how we could
> represent OID (ASN.1)
> as URIs. i proposed two schemes that seem reasonable. we
> would also like to
> hear other opinions.
> these two approaches are as follows:
>
> One encodes the OID as an URL and the other encodes it as an URN:
>
> · Encoding as URL:
> fix a base URL and append the OID in an appropriate format
> (human readable)
> e.g.,
> http://www.etsi.org/oid/itu-t(0)/identified-organization(4)/et
> si(0)/electron
> ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
> The generated URL must be persistent! This means that the
> resulting URL must
> not be used to identify anything else than this OID. And this
> should be the
> case, at least as long as this URL is used to identify this OID.
> Advantages and disadvantages of this approach that we are
> aware of by now,
> are as follows.
> Advantages:
> + Uses the widely know schema of URLs.
> + The owner of the OID can place a specification document
> at the place on
> his web server this URL refers to.
> + If there is no resource (e.g. a specification) at the
> given URL, then it
> is just a unique name like an OID is.
> + Every company can use its own base URL. Some people
> also mentioned the
> idea to use one base URL for all OIDs (e.g. http://www.w3.org/oid/,
> http://www.oid.int or http://www.iso.org/oid). This would
> have the advantage
> to have always the same base URL. The disadvantages would be:
> If the owners
> want to place a specification on the web server, the owning
> company would
> have to maintain web space for all OID owners (perhaps a redirection
> mechanism would solve this?). Additionally, if a company
> wants to use this
> base URL for internal (or even secret) purposes, it might not
> want to use
> the fixed base URL (perhaps, it could just use anyone, if it
> is just for
> internal use?)
> Disadvantages:
> - The company owning the domain name of the base URL must
> ensure that the
> base URL is persistent. It needs to be persistent as long as
> there is one or
> more URLs in use for identifying an OID using this base URL.
> Remind that the
> base URL includes the domain name and any additional directories.
> - If the URL is used just as a unique name without
> referring to any
> resource, it might confuse people.
>
> · Encoding as URN:
> register a NID (see RFC 2141 and RFC 2611) through IANA
> (http://www.iana.org)
> e.g., register "oid" as an NID, define NSS to identify an
> ASN.1 OID. This
> could look like
> urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic
> -signature-sta
> ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
> for instance.
> Advantages and disadvantages of this approach are:
> Advantages:
> + There is a central registration authority for NID.
> + This approach could serve for all OIDs automatically
> (e.g. if the
> registered NID would be "oid").
> + IANA guarantees that NID are registered only once.
> Disadvantages:
> - This mechanism of URNs with registered NIDs seems to be
> rarely used. Some
> people might reject it just because they are not familiar
> with that kind of
> URI.
> - There is no widely used and globally available
> mechanism to dereference an
> URN. Thus, it might not be possible to retrieve a
> specification with the
> given URN as seen with the approach using URLs.
> At first glance, the approach using a URN seems to have the
> advantage to
> guarantee uniqueness. But there is never a hundred percent
> guarantee for
> uniqueness of any data. It is simply impossible. No one can
> securely prevent
> me using any identifier the I want. In both approaches, the
> owner of the
> base URL or of the registered NID has to ensure some properties.
> Just consider the case in which a company is sold. If the
> succeeding owner
> decides to change the rules and reassign all previously used
> identifiers,
> the system does not work, no matter what scheme you use:
> URNs, URLs, or even
> OIDs. Any of these systems only works, if everyone stick to the rules.
>
>
> what do you think is the preferable approach?
>
>
> Karl Scheibelhofer
>
> --
>
> Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
> Institute for Applied Information Processing and Communications (IAIK)
> at Technical University of Graz, Austria, http://www.iaik.at
> Phone: (+43) (316) 873-5540
>
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11964 for <ietf-pkix@imc.org>; Sun, 26 Nov 2000 22:09:20 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA13411; Mon, 27 Nov 2000 17:10:03 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0WErB_; Mon Nov 27 17:09:35 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA22678; Mon, 27 Nov 2000 17:09:34 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0tZwd3; Mon Nov 27 17:09:14 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA21780; Mon, 27 Nov 2000 17:09:13 +1100 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <W06P3DBK>; Mon, 27 Nov 2000 17:08:44 +1100
Message-ID: <73388857A695D31197EF00508B08F29802D25600@ntmsg0131.corpmail.telstra.com.au>
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "'Hoyt L. Kesterson II'" <hoytkesterson@earthlink.net>, "PKIX (E-mail)" <ietf-pkix@imc.org>
Subject: X.509: DR 274 "Attribute Certificate version" - keep [0] tag for issuer
Date: Mon, 27 Nov 2000 17:08:40 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
RE: X.509 (2000) Defect Report 274 "Attribute Certificate version"
Keeping a [0] tag for the issuer v2 field would be beneficial. It would
maintain compatibility of BER-encodings of AttributeCertificate values (2000
edition before and after DR). Replace 11 c) in the DR with the following:
c) In clause 12.1 replace the AttCertIssuer ASN.1 production with:
AttCertIssuer ::= [0] SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateID [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL }
[If style dictates, the tag could be included in the issuer field in
AttributeCertificateInfo instead of in the AttCertIssuer type for the same
effect.]
This would also allow people (in their own implementations) to define a
composite type using CHOICE for the holder and issuer fields that works with
BER-encoded v1 and v2 values.
AttributeCertificateInfo ::= SEQUENCE
{
version AttCertVersion DEFAULT v1,
holder CHOICE {
baseCertificateID [0] IssuerSerial,
subjectName [1] GeneralNames,
v2Form SEQUENCE {
baseCertificateID...
}
},
issuer CHOICE {
v1Form GeneralNames,
v2Form [0] SEQUENCE {
issuerName...
}
},
...
}
P.S. typo in 11 b), should be "INTEGER", not "INTEBER"
> ----------
> From: Hoyt L. Kesterson II [mailto:hoytkesterson@earthlink.net]
> Sent: Monday, 27 November 2000 15:25
> To: "X.509"
> Subject: new defect reports against X.509
>
> Three defects have been reported against X.509. we expect to generate
> Draft Technical Corrigenda within the next few weeks to correct these
> errors (as recommended in the defect reports). Those DTCs will be
> distributed for a three month ballot.
>
> the defect reports can be found at
>
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509an
> dRelated/DR_272.pdf
>
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509an
> dRelated/DR_273.pdf
>
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509an
> dRelated/DR_274.pdf
>
>
> --274
> 10. Nature of Defect:
>
> There is an error in the asn.1 for AttributeCertificateInfo and the text
> below it that explains versioning. Specifically a v1 certificate cannot
> be formed correctly with this ASN.1 because the holder syntax is not
> backward compatible. There is no requirement to carry v1 through to this 4
> th edition text and as such it is recommended that the 4 th edition
> require v2. The changes to the text in order to align with this are
> described below. The other option, which would also solve the problem, is
> to retain the option of v1 or v2 but this would require changing the
> syntax of holder to be a choice of v1 form or v2 form, similar to the way
> issuer is currently handled in the 4 th edition text. However, discussion
> among the defect resolution group to date agreed that it was unnecessary
> to carry over v1 to this edition and that the simplest solution is to
> require v2. Implementations may still support the v1 attribute certificate
> syntax as defined in the 3 rd edition text. Implementations wishing to
> support the v2 syntax would do so as defined in the 4 th edition text.
>
> 11. Solution Proposed by the Source:
>
> a) In clause 12.1 in the AttributeCertificateInfo ASN.1 production,
> replace:
> version AttCertVersion DEFAULT v1,
> with:
> version AttCertVersion --version is v2,
>
> b) In clause 12.1 replace the AttCertVersion ASN.1 production with:
> AttCertVersion ::= INTEBER {v2(1) }
>
> c) In clause 12.1 replace the AttCertIssuer ASN.1 production with:
> AttCertIssuer ::= SEQUENCE {
> issuerName GeneralNames OPTIONAL,
> baseCertificateID [0] IssuerSerial OPTIONAL,
> objectDigestInfo [1] ObjectDigestInfo OPTIONAL }
>
> d) Replace the first paragraph that follows the ASN.1 with the following:
> The version differentiates between different versions of the attribute
> certificate. For attribute certificates issued in accordance with the
> syntax in this specification, version must be v2.
>
> e) The same changes listed in bullets a), b), and c) must also be made in
> Annex A in the attributeCertificateDefinitions module.
>
> 12. Editor's Response:
>
> Accepted solution proposed by source
Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10243 for <ietf-pkix@imc.org>; Sun, 26 Nov 2000 20:24:46 -0800 (PST)
Received: from [38.29.124.196] (ip196.phoenix12.az.pub-ip.psi.net [38.29.124.196]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id XAA25940; Sun, 26 Nov 2000 23:24:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: hoytkesterson@mail.earthlink.net
Message-Id: <a05001901b64790b5a8b6@[38.29.124.196]>
Date: Sun, 26 Nov 2000 21:24:36 -0700
To: "X.509":;
From: "Hoyt L. Kesterson II" <hoytkesterson@earthlink.net>
Subject: new defect reports against X.509
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Three defects have been reported against X.509. we expect to generate
Draft Technical Corrigenda within the next few weeks to correct these
errors (as recommended in the defect reports). Those DTCs will be
distributed for a three month ballot.
the defect reports can be found at
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_272.pdf
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_273.pdf
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_274.pdf
hoyt
Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA27455 for <ietf-pkix@imc.org>; Fri, 24 Nov 2000 21:33:23 -0800 (PST)
Received: from rtfm.com (c212.ppp.tsoft.com [198.144.204.212]) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id VAA05964; Fri, 24 Nov 2000 21:34:30 -0800 (PST)
Received: from rtfm.com (localhost.rtfm.com [127.0.0.1]) by rtfm.com (8.9.3/8.9.3) with ESMTP id VAA19729; Fri, 24 Nov 2000 21:42:51 -0800 (PST) (envelope-from ekr@mike.rtfm.com)
Message-Id: <200011250542.VAA19729@rtfm.com>
To: "Anders Rundgren" <anders.rundgren@telia.com>
cc: "Peter Lipp" <plippml@iaik.at>, "PKIX-List" <ietf-pkix@imc.org>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
In-Reply-To: Your message of "Tue, 21 Nov 2000 20:48:55 +0100." <00d801c053f4$162d7f60$0201a8c0@vincent.se>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 24 Nov 2000 21:42:51 -0800
From: EKR <ekr@rtfm.com>
Anders writes:
> Such apps use TLS/SSL in 99.9% of all cases, and encrypted data would just
> complicate things.
>
> Anyway, IETF's involvement in XMLDSIG was pretty late and probably included
> some "politics" as well so it may not be entirely valid of what the future will bring.
This doesn't accord with my memory. I remember the IETF getting involved
quite early. Certainly, IETFers contributed substantially to the document.
Certainly, there was politics involved.
> Going back to the original question: Do you support the forming of a
> new PKIXML WG?
Yes.
-Ekr
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25294 for <ietf-pkix@imc.org>; Fri, 24 Nov 2000 19:47:14 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id TAA28226; Fri, 24 Nov 2000 19:49:49 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNF22JG7>; Fri, 24 Nov 2000 19:48:15 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B94D@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Denis Pinkas <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Fri, 24 Nov 2000 19:48:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Denis,
It's my understanding that IETF WGs are governed by the list, not the floor.
I regret to note that the list to date does not appear to support your
proposed alternative to OCSP certID syntax expansion. As I've said
repeatedly, I have no other task but to record the WG's consensus. As lead
author on OCSP, I have to at some point make a call in favor of forward
progress. It appears to me that we do in fact have rough consensus on the
certID syntax issue. You're of course free to bring this up on the floor in
San Diego. That said, would you agree however that a floor consensus isn't
necessarily a WG consensus, given that some in the WG may be constrained in
their travel budgets?
Mike
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28488 for <ietf-pkix@imc.org>; Fri, 24 Nov 2000 01:37:58 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA75858; Fri, 24 Nov 2000 10:45:05 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA18498; Fri, 24 Nov 2000 10:38:25 +0100
Message-ID: <3A1E3713.A1CFE45D@bull.net>
Date: Fri, 24 Nov 2000 10:38:27 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <MMyers@verisign.com>
CC: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <2F3EC696EAEED311BB2D009027C3F4F401C5B8FC@vhqpostal.verisign.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael,
> All,
>
> This thread has drifted away from its original intent. The question is, the
> OCSPv2 authors propose one means of expanding RFC2560's certID syntax,
> recognizing that doing so would cycle RFC2560 at proposed vs. moving it
> forward. OCSPv2's expanded certificate identification syntax remains as
> proposed in the absence of rough consensus in support of alternatives.
I do not see this as a reason of keeping a proposal which does not meet
either a rough consensus. We will certainly discuss this issue (among
others) at the San Diego meeting.
BTW, here an extract from your E-mail from Fri, 17 Nov 2000 (RE: DPV vs SCV)
:
[Denis]: DPV and DPD can only be considered as extensions, if you agree with
the meaning of the status I explained in two E-mails sent to you. I am still
awaiting a detailed response from you on this matter, and globally on my
previous E-mail.
[Mike]: I had hoped that you considered my prior emails as responsive. Some
of your comments I didn't take to be actionable in the absence of a broader
consensus. I'll take another look at them today to see if I missed
something obvious.
I am still awaiting a response.
Denis
> Last
> call will be asked for in San Diego based on this request, so please take
> take 1/2 hour or so to read through the drafts and make your opinions known
> on the list regarding the certID issue as this will feed into our San Diego
> meeting.
>
> Mike
>
> PS: BTW, "OCSPv2 authors" is and will continue to include our very dear
> friend Rich Ankney.
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28399 for <ietf-pkix@imc.org>; Fri, 24 Nov 2000 01:37:13 -0800 (PST)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A703A1B0116; Fri, 24 Nov 2000 10:38:11 +0100
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0 17/November/2000); Fri, 24 Nov 2000 10:36:32 +0100
From: "Karl Scheibelhofer" <Karl.Scheibelhofer@iaik.at>
To: "IETF PKIX Mailing List" <ietf-pkix@imc.org>
Subject: OIDs as URIs
Date: Fri, 24 Nov 2000 10:36:31 +0100
Message-ID: <NDBBJJNFOMNNKFDPLCDJAEFCCEAA.Karl.Scheibelhofer@iaik.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
in the last ETSI ESI meeting we discussed how we could represent OID (ASN.1)
as URIs. i proposed two schemes that seem reasonable. we would also like to
hear other opinions.
these two approaches are as follows:
One encodes the OID as an URL and the other encodes it as an URN:
· Encoding as URL:
fix a base URL and append the OID in an appropriate format (human readable)
e.g.,
http://www.etsi.org/oid/itu-t(0)/identified-organization(4)/etsi(0)/electron
ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
The generated URL must be persistent! This means that the resulting URL must
not be used to identify anything else than this OID. And this should be the
case, at least as long as this URL is used to identify this OID.
Advantages and disadvantages of this approach that we are aware of by now,
are as follows.
Advantages:
+ Uses the widely know schema of URLs.
+ The owner of the OID can place a specification document at the place on
his web server this URL refers to.
+ If there is no resource (e.g. a specification) at the given URL, then it
is just a unique name like an OID is.
+ Every company can use its own base URL. Some people also mentioned the
idea to use one base URL for all OIDs (e.g. http://www.w3.org/oid/,
http://www.oid.int or http://www.iso.org/oid). This would have the advantage
to have always the same base URL. The disadvantages would be: If the owners
want to place a specification on the web server, the owning company would
have to maintain web space for all OID owners (perhaps a redirection
mechanism would solve this?). Additionally, if a company wants to use this
base URL for internal (or even secret) purposes, it might not want to use
the fixed base URL (perhaps, it could just use anyone, if it is just for
internal use?)
Disadvantages:
- The company owning the domain name of the base URL must ensure that the
base URL is persistent. It needs to be persistent as long as there is one or
more URLs in use for identifying an OID using this base URL. Remind that the
base URL includes the domain name and any additional directories.
- If the URL is used just as a unique name without referring to any
resource, it might confuse people.
· Encoding as URN:
register a NID (see RFC 2141 and RFC 2611) through IANA
(http://www.iana.org)
e.g., register “oid” as an NID, define NSS to identify an ASN.1 OID. This
could look like
urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta
ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1)
for instance.
Advantages and disadvantages of this approach are:
Advantages:
+ There is a central registration authority for NID.
+ This approach could serve for all OIDs automatically (e.g. if the
registered NID would be “oid”).
+ IANA guarantees that NID are registered only once.
Disadvantages:
- This mechanism of URNs with registered NIDs seems to be rarely used. Some
people might reject it just because they are not familiar with that kind of
URI.
- There is no widely used and globally available mechanism to dereference an
URN. Thus, it might not be possible to retrieve a specification with the
given URN as seen with the approach using URLs.
At first glance, the approach using a URN seems to have the advantage to
guarantee uniqueness. But there is never a hundred percent guarantee for
uniqueness of any data. It is simply impossible. No one can securely prevent
me using any identifier the I want. In both approaches, the owner of the
base URL or of the registered NID has to ensure some properties.
Just consider the case in which a company is sold. If the succeeding owner
decides to change the rules and reassign all previously used identifiers,
the system does not work, no matter what scheme you use: URNs, URLs, or even
OIDs. Any of these systems only works, if everyone stick to the rules.
what do you think is the preferable approach?
Karl Scheibelhofer
--
Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03862 for <ietf-pkix@imc.org>; Thu, 23 Nov 2000 23:08:17 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id XAA10926 for <ietf-pkix@imc.org>; Thu, 23 Nov 2000 23:10:56 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNF22FJ9>; Thu, 23 Nov 2000 23:09:22 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B8FC@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Thu, 23 Nov 2000 23:09:21 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
All,
This thread has drifted away from its original intent. The question is, the
OCSPv2 authors propose one means of expanding RFC2560's certID syntax,
recognizing that doing so would cycle RFC2560 at proposed vs. moving it
forward. OCSPv2's expanded certificate identification syntax remains as
proposed in the absence of rough consensus in support of alternatives. Last
call will be asked for in San Diego based on this request, so please take
take 1/2 hour or so to read through the drafts and make your opinions known
on the list regarding the certID issue as this will feed into our San Diego
meeting.
Mike
PS: BTW, "OCSPv2 authors" is and will continue to include our very dear
friend Rich Ankney.
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25449 for <ietf-pkix@imc.org>; Thu, 23 Nov 2000 19:55:41 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id TAA26517; Thu, 23 Nov 2000 19:51:41 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XNFTLW6Y>; Thu, 23 Nov 2000 19:55:38 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B8FA@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: "Bland, Graham" <Graham.Bland@open-talk.co.uk>, "'Simon Tardell'" <simon.tardell@smarttrust.com>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Thu, 23 Nov 2000 19:55:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Graham,
Practices regarding protection of the corresponding private key come to
mind.
Mike
> -----Original Message-----
> From: Bland, Graham [mailto:Graham.Bland@open-talk.co.uk]
> Sent: Monday, November 20, 2000 6:59 AM
> To: 'Simon Tardell'; ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
>
> Simon,
>
> There is no requirement that I can see for the OCSP responder to be
> authorised or trusted by the issuer, I quote
>
> All definitive response messages SHALL be digitally signed. The key
> used to sign the response MUST belong to one of the following:
>
> -- the CA who issued the certificate in question
> -- a Trusted Responder whose public key is trusted by the requester
> -- a CA Designated Responder (Authorized Responder) who holds a
> specially marked certificate issued directly by the CA,
> indicating
> that the responder may issue OCSP responses for that CA
>
> The second case here implies trust only between the requestor and the
> responder.
>
> Also in section 4.2.2.2 local configuration of OCSP signing
> authority by the
> requestor is allowed bypassing any CA authority or involvement.
>
> Graham Bland
>
>
> -----Original Message-----
> From: Simon Tardell [mailto:simon.tardell@smarttrust.com]
> Sent: 20 November 2000 14:39
> To: 'Margus Freudenthal'; Simon Tardell; ietf-pkix@imc.org
> Cc: 'Michael Myers'
> Subject: RE: OCSP identifiers
>
>
> > Hello.
>
> Hi.
>
> > Simon Tardell wrote:
> > >
> > > CertHash is proposed to solve the problem of compromise
> of the issuer
> key.
> > > It turns the question from a revocation query to an
> issuance query. It
> also
> > > turns the responder from being someone who answers on
> delegation into
> > > someone who is an authority on its own (i.e. it can, in effect,
> invalidate
> > > the issuer).
> >
> > Well, OCSP response is currently signed by OCSP responder
> > (which may or may not be the CA). If you do not trust the
> OCSP responder,
> then even
> > CRL-based OCSP service can't give you satisfactory answers
> > because they do not contain CA's signature. If you want
> assurance given
> by CA, you
> > should download the CRL and ceck it (and steer clear of the OCSP
> > protocol).
>
> Not at all. My trust in the OCSP responder derives from my
> trust in the CA.
> The OCSP responses must (and that's a MUST...) either be signed by the
> issuer, or someone authorized (by the issuer) to do so. Other
> models can be
> imagined, such as the one you advocate, but they are very
> different model.
> I'm not against such models, but they should not break the
> primary mode of
> the protocol.
>
> If the issuer revokes the authorization of the responder for whatever
> reason, I expect it to revoke the responder keys. That's
> assurance enough
> for most purposes. How the client learn about this is a
> deployment issue.
>
> Simon.
>
> Simon Tardell, Software Architect, SmartTrust
> voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
> simon.tardell@smarttrust.com, http://www.smarttrust.com
> ______________________________________________________________
> _________
>
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this
> e-mail is not intended to create legally binding commitments on
> behalf of any company in the British Interactive Broadcasting
> Holdings Limited group, nor do its contents reflect the corporate
> views or policies of any such company. Any unauthorised disclosure,
> use or dissemination, either whole or partial, is prohibited. If you
> are not the intended recipient of the message, please notify the
> sender immediately.
> ______________________________________________________________
> _________
>
Received: from antares.caixa.gov.br ([200.252.229.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26961 for <ietf-pkix@imc.org>; Thu, 23 Nov 2000 09:29:01 -0800 (PST)
Received: from cd0000nt500.coredf.caixa ([200.252.229.19]) by antares.caixa.gov.br (8.10.2/8.10.2) with ESMTP id eANHQDH01233 for <ietf-pkix@imc.org>; Thu, 23 Nov 2000 15:26:14 -0200 (EDT)
Received: by cd0000nt500.coredf.caixa with Internet Mail Service (5.5.2653.19) id <XN72RMMB>; Thu, 23 Nov 2000 15:25:23 -0200
Message-ID: <4A0CBE8C0C60D311B1ED009027870EBB01DC8AA7@cd0000nt501.coredf.caixa>
From: Sergio Albuquerque <sergio.albuquerque@caixa.gov.br>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject:
Date: Thu, 23 Nov 2000 15:25:23 -0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05572.5CBA4D80"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C05572.5CBA4D80
Content-Type: text/plain;
charset="iso-8859-1"
subscribe pki
------_=_NextPart_001_01C05572.5CBA4D80
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE></TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2 FACE="Arial">subscribe pki</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C05572.5CBA4D80--
Received: from antares.caixa.gov.br ([200.252.229.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26646 for <ietf-pkix@imc.org>; Thu, 23 Nov 2000 09:24:52 -0800 (PST)
Received: from cd0000nt500.coredf.caixa ([200.252.229.19]) by antares.caixa.gov.br (8.10.2/8.10.2) with ESMTP id eANHPsH01009 for <ietf-pkix@imc.org>; Thu, 23 Nov 2000 15:25:55 -0200 (EDT)
Received: by cd0000nt500.coredf.caixa with Internet Mail Service (5.5.2653.19) id <XN72RMLW>; Thu, 23 Nov 2000 15:25:04 -0200
Message-ID: <4A0CBE8C0C60D311B1ED009027870EBB01DC8AA6@cd0000nt501.coredf.caixa>
From: Sergio Albuquerque <sergio.albuquerque@caixa.gov.br>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: PKI Mailing List
Date: Thu, 23 Nov 2000 15:25:03 -0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05572.50DCBC50"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C05572.50DCBC50
Content-Type: text/plain;
charset="iso-8859-1"
What can I do to subscribe this list ?
Thanks.
Sergio Albuquerque
mailto:sergio.albuquerque@caixa.gov.br
------_=_NextPart_001_01C05572.50DCBC50
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>PKI Mailing List</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2 FACE="Arial">What can I do to subscribe this list ?</FONT>
<BR><FONT SIZE=2 FACE="Arial">Thanks.</FONT>
<BR><FONT SIZE=2 FACE="Arial">Sergio Albuquerque</FONT>
<BR><FONT SIZE=2 FACE="Arial"><A HREF="mailto:sergio.albuquerque@caixa.gov.br">mailto:sergio.albuquerque@caixa.gov.br</A> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C05572.50DCBC50--
Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03501 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 13:57:18 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id <V9A7WT2H>; Wed, 22 Nov 2000 13:52:48 -0800
Message-ID: <1BE57AA01A5ED411866500B0D049657B42A569@exchange.cylink.com>
From: "Covey, Carlin" <ccovey@cylink.com>
To: "'ambarish@valicert.com'" <ambarish@valicert.com>, "'paul.hoffman@vpnc.org'" <paul.hoffman@vpnc.org>
Cc: PKIX-List <ietf-pkix@imc.org>
Subject: SCVP RevocationInfo
Date: Wed, 22 Nov 2000 13:52:40 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Ambarish and/or Paul,
I was wondering about the interpretation of "MAY" in the following section
from draft-ietf-pkix-scvp-03.txt. The sentence beginning "Note..." cites
one reason that the server might not use the revocation information
proffered by the client (i.e., if it is not applicable). But I wonder if
the server is obligated to use the revocation information if it is
applicable. For example, suppose the client proffers a recent OCSP response
that indicates that a certificate has been revoked, but the server has an
older (but not superseded) CRL that does not show the revocation. Is the
server free to ignore the OCSP response? This doesn't seem safe. If the
SCVP server doesn't understand OCSP responses, must it return the response
"22 The request included unrecognized items; aborting"? It doesn't seem
safe for the SCVP server to return "1 The request included unrecognized
items; continuing" because there doesn't appear to be a means for telling
the client which items were unrecognizable.
- Carlin Covey
Cylink Corp.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3.14 RevocationInfo
The RevocationInfo item specifies to the server revocation information
such as CRLs and OCSP [OCSP] responses that the server MAY use when
validating certificate chains. The purpose of the RevocationInfo item
is to provide revocation information to the server that the server may
not have access to, such as an OCSP response that the client received
along with the certificate. Note that the information in the
RevocationInfo item might not be used by the server, such as if the
information is for certificates that the server does not use in chain
building.
The types of revocation proof that can be provided are:
- CRL
- OCSP response
[[[Need to specify the format of the extensions for both CRLs and
for OCSP responses.]]]
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25377 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 11:01:30 -0800 (PST)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id eAMIs9D12157 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 10:54:09 -0800 (PST)
Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G4FWV700.RJ9; Wed, 22 Nov 2000 11:01:55 -0800
Message-ID: <3A1C1824.1030407@netscape.com>
Date: Wed, 22 Nov 2000 11:01:56 -0800
From: thayes@netscape.com (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: Michael Zolotarev <mzolotarev@baltimore.com>, PKIX-List <ietf-pkix@imc.org>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
References: <D44EACB40164D311BEF00090274EDCCAD8C0E7@sydneymail1.jp.zergo.com.au> <005201c0546d$1855ab90$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote:
> What I have tried to explain (in vain) is that ACs should be a self-contained (XMLDSIG) signed containers having one of four different link styles to a Holder (none, named, PK, PKC). And that the attribute part itself should be entirely app-specific.
You mean like this: (paraphrased from the AC ID)
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion DEFAULT v1,
holder Holder,
issuer AttCertIssuer,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute
}
Holder ::= CHOICE { -- modified!
baseCertificateID [0] IssuerSerial,
entityName [1] GeneralNames,
publicKeyDigest [2] DigestInfo,
publicKeyCertDigest [3] DigestInfo
}
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue
-- at least one value is required
}
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType
id-xml-attribute ::= { id-aca XX }
-- attribute value SYNTAX is UTF8String, which is XML
Terry Hayes
thayes@netscape.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15565 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 08:16:57 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22207; Wed, 22 Nov 2000 08:17:38 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA03962; Wed, 22 Nov 2000 11:17:37 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA26033; Wed, 22 Nov 2000 11:17:36 -0500 (EST)
Message-ID: <3A1BF117.F2AC440C@sun.com>
Date: Wed, 22 Nov 2000 11:15:19 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <Denis.Pinkas@bull.net>
CC: stephen.farrell@baltimore.ie, ietf-pkix@imc.org
Subject: Re: Cross-organizational ACs
References: <sa10f961.033@prv-mail20.provo.novell.com> <3A11BAAC.4140F4EF@sun.com> <3A126549.D617698A@baltimore.ie> <3A12AA3C.6F771B38@sun.com> <3A12AF55.279C2779@baltimore.ie> <3A12B13D.2BFBAD78@sun.com> <3A13AD8F.544971B8@bull.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Denis Pinkas wrote:
> Besides Stephen (and possibly the co-editors), it would be nice to
> know who is (or is not) in favour of AAControls.
This document has already passed WG Last Call and IETF Last Call.
Apparently, the consensus of the working group was to include the
AAControls extension. Although you and I don't agree with this, it's
probably too late to do anything about it unless there is a *major*
problem with the extension.
AAControls is an optional extension. It can be ignored. I suggest that
we allow it to be included for now and focus our energies on providing a
better delegation system (probably a profile of X.509 delegation,
focussed on the needs of Internet protocols). If we can accomplish that,
we can propose that AAControls be deprecated when ac509prof is ready to
move to Draft Standard status. After all, one purpose of Proposed
Standard documents (as described in RFC 2026) is to "gain experience and
to validate, test, and clarify the specification."
> If you plan to attend the next IETF meeting, I would like to have a
> chat with you, so that we can possibly define such delegation
> schemes. No syntax changes planed in the definition of ACs, simply
> the definition of rules on how to use them in the context of
> delegation.
I would love to do this. Anyone else who would like to participate,
please send me email and I will arrange an informal meeting.
-Steve
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15462 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 08:15:50 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21458; Wed, 22 Nov 2000 08:16:40 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA03653; Wed, 22 Nov 2000 11:16:36 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA25925; Wed, 22 Nov 2000 11:16:35 -0500 (EST)
Message-ID: <3A1BF0DA.4089E8C3@sun.com>
Date: Wed, 22 Nov 2000 11:14:18 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Gindin/Watson/IBM <tgindin@us.ibm.com>
CC: ietf-pkix@imc.org
Subject: Re: Holder
References: <OF45ED8E84.6417B69F-ON85256998.00584C5A@somers.hqregion.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Apparently, we cannot rule out the possibility that someone might want
to use an AC whose holder field was tied to a PKC without also providing
the associated PKC.
In that case (and given the debugging benefits of format 9 over format
5), let's go with formats 2, 4, and 9. Here is my revised proposal:
I propose that the following text be incorporated into the next version
of ac509 (along with text explaining the various formats, how they must
be handled for validation purposes, and why each one might be preferred
to the others).
AC issuers SHOULD use only formats 2, 4, or 9. They MAY use other
formats, as necessary. AC verifiers SHOULD support formats 2, 4, and
9 (subject to specific requirements and configuration). They MAY
support other formats.
Any objections? Agreement? General consensus?
-Steve
P.S. I am proposing this change at this late date (after IETF Last Call
has closed) to address the security risks Polar pointed out when using
format 2 (entityName only) with a potentially inconsistent namespace.
Tom Gindin/Watson/IBM wrote:
>
> I don't have a specific example of an AC accompanying a signed
> document or transaction, either with or without a PKC. In fact, AFAIK
> there is no place in either CMS or XMLDSIG to put an AC, although AC's
> could go into the attributes (signed or unsigned) in CMS and into
> SignatureProperty in XMLDSIG. It is legal to specify an X509Data in
> XMLDSIG which does not contain the full PKC (see section 4.4.4 of
> http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/), and it is legal to
> omit a PKC from SignedData in CMS (see section 5.1 of RFC 2630) "if it is
> expected that recipients have an alternate means of obtaining necessary
> certificates".
> I am suggesting that these are reasonable places for an AC to go in a
> push scenario. However, I am not personally involved in any current
> development of software using AC's, so anyone who wishes to dismiss my
> opinions on these matters as pure theory may do so.
>
> Tom Gindin
>
> Steve Hanna <steve.hanna@sun.com> on 11/14/2000 02:57:58 PM
>
> To: Tom Gindin/Watson/IBM@IBMUS
> cc: ietf-pkix@imc.org
> Subject: Re: Holder
>
> Do you have a specific example where an AC whose Holder component was
> tied to a PKC would accompany a signed document (or other object) but
> the PKC would not? This seems somewhat unlikely to me.
>
> I don't mind recommending format 9 instead of format 5, based only on
> easier debugging and a suspicion that the entityName might some day be
> useful for finding the PKC. But I would be more comfortable if we had a
> specific scenario where the entityName is needed to find the PKC.
>
> -Steve
>
> Tom Gindin/Watson/IBM wrote:
> >
> > The primary use I can think of for format 7, 9, or 11 is to permit
> an
> > AC to accompany (or simply be stored with) a signed document,
> transaction,
> > or message without requiring the PKC to do so. The RP can then look up
> the
> > PKC. As I have stated before, in any case like this format 11 or format
> 9
> > is preferable to format 5. Formats 4 and 5 are appropriate when the PKC
> > accompanies the AC or precedes it in a protocol, but not otherwise.
> > Since format 9 (or format 11) is preferable to format 5 when the AC
> is
> > sent or stored independently of the PKC and also carries out all the
> > functions of format 5, I would replace your references to format 5 by
> > references to format 9 (or format 11). Formats 2, 4, and 9 make a
> > reasonable minimal set, as do 2, 4, and 11.
> >
> > Tom Gindin
> >
> > Steve Hanna <steve.hanna@sun.com> on 11/10/2000 10:56:55 AM
> >
> > To: ietf-pkix@imc.org
> > cc:
> > Subject: Re: Holder
> >
> > Well, my list of scenarios does not seem to be helping us resolve this
> > issue.
> >
> > I will make a specific proposal, seeking comments or consensus. Since
> > none of the scenarios demonstrates a need for hints in Holder formats
> > that include the objectDigestInfo component, I propose that we adopt the
> > following recommendation, which would be incorporated into the next
> > version of ac509 (along with text explaining the various formats, how
> > they must be handled for validation purposes, and why each one might be
> > preferred to the others).
> >
> > AC issuers SHOULD use only formats 2, 4, or 5. They MAY use other
> > formats, as necessary. AC verifiers SHOULD support formats 2, 4, and
> > 5 (subject to specific requirements and configuration). They MAY
> > support other formats.
> >
> > I welcome comments from others on this proposal. A good argument can be
> > made for replacing format 5 with format 9, if only for debugging
> > purposes. But I'd rather not recommend support for both, if possible.
> >
> > -Steve
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22300 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 03:12:52 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21594; Wed, 22 Nov 2000 06:13:46 -0500 (EST)
Message-Id: <200011221113.GAA21594@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-12.txt
Date: Wed, 22 Nov 2000 06:13:45 -0500
Sender: nsyracus@cnri.reston.va.us
--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 Time Stamp
Protocols (TSP)
Author(s) : C. Adams, P. Cain, D. Pinkas, R. Zuccherato
Filename : draft-ietf-pkix-time-stamp-12.txt
Pages : 25
Date : 21-Nov-00
A time stamping service supports assertions of proof that a datum
existed before a particular time. This document describes the format
of a request sent to a Time Stamping Authority (TSA) and of the
response that is returned. It also establishes several security-
relevant requirements for TSA operation, with regards to processing
requests to generate responses. A TSA may be operated as a Trusted
Third Party (TTP) service, though other operational models may be
appropriate, e.g. an organization might require a TSA for internal
time stamping purposes.
Non-repudiation services [ISONR] require the ability to establish the
existence of data before specified times. This protocol may be used as
a building block to support such services. An example of how to prove
that a digital signature was generated during the validity period of
a public key certificate is given in an annex.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-12.txt
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-time-stamp-12.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:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-time-stamp-12.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="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001121111515.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-time-stamp-12.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-time-stamp-12.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001121111515.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22268 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 03:12:48 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21568; Wed, 22 Nov 2000 06:13:41 -0500 (EST)
Message-Id: <200011221113.GAA21568@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-01.txt
Date: Wed, 22 Nov 2000 06:13:41 -0500
Sender: nsyracus@cnri.reston.va.us
--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 : Algorithms and Identifiers for the
Internet X.509 Public Key Infrastructure
Certificate and CRL Profile
Author(s) : L. Bassham, R. Housley, W. Polk
Filename : draft-ietf-pkix-ipki-pkalgs-01.txt
Pages : 26
Date : 21-Nov-00
This document specifies algorithm identifiers and ASN.1 encoding
formats for digital signatures and subject public keys used in the
Internet X.509 Public Key Infrastructure (PKI). Digital signatures
are used to sign certificates and certificate revocation lists
(CRLs). Certificates include the public key of the named subject.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-01.txt
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-ipki-pkalgs-01.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:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-ipki-pkalgs-01.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="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001121111504.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-pkalgs-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-ipki-pkalgs-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001121111504.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22253 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 03:12:44 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21548; Wed, 22 Nov 2000 06:13:37 -0500 (EST)
Message-Id: <200011221113.GAA21548@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-new-part1-03.txt
Date: Wed, 22 Nov 2000 06:13:37 -0500
Sender: nsyracus@cnri.reston.va.us
--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 Certificate Infrastructure
and CRL Profile
Author(s) : R. Housley, W. Ford, W. Polk, D. Solo
Filename : draft-ietf-pkix-new-part1-03.txt
Pages : 118
Date : 21-Nov-00
This is the first draft of a specification based upon RFC 2459. When
complete, this specification will obsolete RFC 2459. This
specification includes numerous edits and clarifications. The most
notable departures from RFC 2459 are found in Section 6, Path
Validation. In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with
information embedded in earlier sections. For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path. However,
parameter inheritance was omitted from the path validation algorithm in RFC 2459. In this draft, the path validation algorithm has a
comprehensive and extremely detailed description. Details such as
parameter inheritance are covered thoroughly. In addition, this
draft anticipates certain corrections proposed in the X.509 standard
for the policy processing aspects of path validation.
A new section 6.3, CRL validation, has been added as well. This
section provides a supplement to the path validation algorithm that
determines if a particular CRL may be used to verify the status of a
particular certificate. (The basic path validation algorithm is, by
design, independent of the type and format of status information.)
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet. An overview of the approach and model are provided
as an introduction. The X.509 v3 certificate format is described in
detail, with additional information regarding the format and
semantics of Internet name forms (e.g., IP addresses). Standard
certificate extensions are described and one new Internet-specific
extension is defined. A required set of certificate extensions is
specified. The X.509 v2 CRL format is described and a required
extension set is defined as well. An algorithm for X.509 certificate
path validation is described. Supplemental infor
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-03.txt
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-new-part1-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:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-new-part1-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="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001121111453.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-new-part1-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-new-part1-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001121111453.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA16353 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 02:15:52 -0800 (PST)
Received: from mega (t3o69p49.telia.com [62.20.145.49]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id LAA27965; Wed, 22 Nov 2000 11:16:33 +0100 (CET)
Message-ID: <005201c0546d$1855ab90$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Michael Zolotarev" <mzolotarev@baltimore.com>, "Stephen Kent" <kent@bbn.com>, "Nada Kapidzic Cicovic" <nada@entegrity.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCAD8C0E7@sydneymail1.jp.zergo.com.au>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
Date: Wed, 22 Nov 2000 11:15:08 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA16355
Michael,
> > > WHERE: IETF AAA WG. I just think it'd be a right place for it.
> >
> > I can't find any descriptions of the AAA WG.
>
> http://www.ietf.org/html.charters/aaa-charter.html
OK, I went through the description of their goals and it does IMO not match
the scope of my anticipated XML-AC. RADIUS and network acess etc. is a rather
specific thing while ACs are not.
What I have tried to explain (in vain) is that ACs should be a self-contained (XMLDSIG)
signed containers having one of four different link styles to a Holder (none, named, PK, PKC).
And that the attribute part itself should be entirely app-specific.
That the path validation protocols have a lot of scope defintion problems is correct,
but there has been clear indication of a desire to use XML when these problems
have been resolved.
Bur right now the whole issue is a lost case as the only information we got, is that Steven Kent
want this stuff outside of PKIX.
I think that I pass on this until I see some action from the IETF area directors.
/Anders
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA12441 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 01:36:37 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id TAA01880; Wed, 22 Nov 2000 19:44:26 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <W0XV10H3>; Wed, 22 Nov 2000 20:34:58 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCAD8C0E7@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Anders Rundgren <anders.rundgren@telia.com>, Michael Zolotarev <mzolotarev@baltimore.com>, Stephen Kent <kent@bbn.com>, Nada Kapidzic Cicovic <nada@entegrity.com>
Cc: PKIX-List <ietf-pkix@imc.org>
Subject: RE: Scope of PKIXML-WG. Was: Should PKIX protocols support XML w ell?
Date: Wed, 22 Nov 2000 20:34:50 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
> > I would certainly hope that IETF is the right place to
> handle *this*. But
> > first we have to decide what exactly *this* is.
>
> I have been encouraged to submit a BOF on this.
> Unfortunately none of the area
> managers have responded to my request for action. To
> "settle" the scope
> should IMO not be done by those who do not intend to participate.
>
Anders, before embarking on something which is not exactly within the
mainstream of the current PKI flow, we should be more than certain on the
exact scope of the undertaking. By looking at the recent discussion I could
see at least 3 possible 'scopes', with the only common thing - XML. I don't
think just saying "XML in PKI" is sufficient to form a WG. We have to be
more specific than that.
This is why I've outlined 1,2,3 in my previous message, and suggested that
(3) may have some rationale. 1 and 2 don't, IMO.
>
> > Let me elaborate on the (3):
> > WHAT: Activity. Not a WG.
>
> Why not?
If we accept that (3) is what we want to do, then there is not enough 'meat'
for a WG. It can be covered by existing (extended?) charter of AAA.
>
> > WHERE: IETF AAA WG. I just think it'd be a right place for it.
>
> I can't find any descriptions of the AAA WG.
http://www.ietf.org/html.charters/aaa-charter.html
>
> > Outside of PKIX, which maintains its purity and
> concentrates on core protocols and
> > structures.
>
> PKIXML would not nessesary be unpure. Some PKIX's members
> are undoubtly purists.
by saying 'pure' I mean PKC and closely related structures and protocols.
All in ASN.
>
> > HOW: I can see two possible approaches here:
> > a) by doing it from scratch
> > b) by accommodating the work currently being done by vendor
> > consortiums.
>
> a) Doing _what_ from scratch?
Defining XML-based Authentication framework starting from scratch, without
any relations to what's other have being doing.
> b) It can in some cases be done. But rather seldom as the
> consortiums usually
> are commercial and don't want interference. S2ML, OBI, WAP,
> IDENTRUS, SetCo etc. all
> belong to this category.
I think that the attitude is changing. WAP came back to IETF with a proposal
to merge. The same with IDENTRUS - they want to stick to standards.
> From en engineer's point of view I
> find it very uninspiring to to spend
> a lot of energy on nit-picking instead of being there when
> the ground is made. The discussions
> regarding ACs is an example of working in total darkness as
> the questions really are: Does this work?
> Will it get generally (=MSFT) be supported?
>
> AFAIK we have several possible work items for PKIXML
> - AC's
> - Path validation protocols (I am not fully updated on these)
>
I would suggest (not necessarily support, though, at that stage) to stick to
AC and authentication framework. Path validation protocols have enough
problems with scoping and defining boundaries and responsibilities. Encoding
is not the biggest of the concerns there.
> Anders
>
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA07037 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 00:52:40 -0800 (PST)
Received: from mega (t5o69p29.telia.com [213.64.110.29]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA28046; Wed, 22 Nov 2000 09:53:23 +0100 (CET)
Message-ID: <003c01c05461$7a201e20$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Michael Zolotarev" <mzolotarev@baltimore.com>, "Stephen Kent" <kent@bbn.com>, "Nada Kapidzic Cicovic" <nada@entegrity.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCAD8BF19@sydneymail1.jp.zergo.com.au>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
Date: Wed, 22 Nov 2000 09:51:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA07041
Michael,
> I would certainly hope that IETF is the right place to handle *this*. But
> first we have to decide what exactly *this* is.
I have been encouraged to submit a BOF on this. Unfortunately none of the area
managers have responded to my request for action. To "settle" the scope
should IMO not be done by those who do not intend to participate.
___MEMBERZ RULEZ!___
> Let me elaborate on the (3):
> WHAT: Activity. Not a WG.
Why not?
> WHERE: IETF AAA WG. I just think it'd be a right place for it.
I can't find any descriptions of the AAA WG.
> Outside of PKIX, which maintains its purity and concentrates on core protocols and
> structures.
PKIXML would not nessesary be unpure. Some PKIX's members are undoubtly purists.
>Not in W3C, which shouldn't be dealing with anything higher than
> core XML (language, schemas, basic XML signing etc).
Here I may actually agree :-)
> HOW: I can see two possible approaches here:
> a) by doing it from scratch
> b) by accommodating the work currently being done by vendor
> consortiums.
a) Doing _what_ from scratch?
b) It can in some cases be done. But rather seldom as the consortiums usually
are commercial and don't want interference. S2ML, OBI, WAP, IDENTRUS, SetCo etc. all
belong to this category. From en engineer's point of view I find it very uninspiring to to spend
a lot of energy on nit-picking instead of being there when the ground is made. The discussions
regarding ACs is an example of working in total darkness as the questions really are: Does this work?
Will it get generally (=MSFT) be supported?
AFAIK we have several possible work items for PKIXML
- AC's
- Path validation protocols (I am not fully updated on these)
Anders
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA00631 for <ietf-pkix@imc.org>; Wed, 22 Nov 2000 00:02:43 -0800 (PST)
Received: from mega (t4o69p44.telia.com [62.20.145.164]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA19384; Wed, 22 Nov 2000 09:00:49 +0100 (CET)
Message-ID: <002e01c0545a$2435a860$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Michael Zolotarev" <mzolotarev@baltimore.com>, "Peter Lipp" <plippml@iaik.at>, "EKR" <ekr@rtfm.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCAD8BF2D@sydneymail1.jp.zergo.com.au>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
Date: Wed, 22 Nov 2000 08:59:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA00634
> Let me say that XMLDSIG is not a replacement for PKCS#7-signing either:
> PKCS#7 is a general-purpose structure for signing data blobs. And XMLDSIG is
> a format which was designed specifically to be 'native' for signing XML
> documents.
> As much as you wouldn't normally use PKCS#7 to sign XML documents today, you
> wouldn't use XMLDSIG to sign a random binary data block. We are talking
> practical use, of course, not a theory.
I don't get this at all. PKCS #7 is indeed used to sign documents like EDI data which
is not binary. It is a part of the OBI standard which I am actively working with.
Regarding XMLDSIG it is equally well fitted to sign "blob" data although it must be converted to
BASE64 and inserted in an XML container document. This is how you must treat a lot of
non-xml data like word-documents etc. A part from using 30% more space than native
blobs do, this will happen. Today it may be theory due to the short time XMLDSIG has
been avialable. Yes, it is not even RFC yet.
Anders
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA06231 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 20:33:24 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA04404; Wed, 22 Nov 2000 14:40:56 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <W0XV10C4>; Wed, 22 Nov 2000 15:32:09 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCAD8BF75@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Jeff Davis <jeff.davis@zetnet.co.uk>
Cc: PKIX-List <ietf-pkix@imc.org>
Subject: RE: Scope of PKIXML-WG. Was: Should PKIX protocols support XML w ell?
Date: Wed, 22 Nov 2000 15:32:07 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Jeff,
>tell me if I am missing something here that my JAVA
> programmers do not need to know the finer arts of ASN-1 to actual
> interface to it!
Jeff, let me assure you that your "JAVA programmers do not need to know the
finer arts of ASN-1 to actual interface to it!"
To handle certificates and related stuff in your applications, you don't
need to posess any knowledge of ASN1 BER/DER. As a matter of fact you don't
even need to know much, or anything at all, about internals of PKCS10, PKCS7
etc. There are APIs to handle it. The libraries in Java, C++, commercial or
free. You don't need to be bothered with anything else but the actual *use*
of the certificates, signatures and whatever else. But the *use* of that
stuff remains the same, be it in ASN or XML.
BTW Just a few days ago there was an announcement from Sun:
http://java.sun.com/j2se/1.3/docs/guide/security/CryptoSpec.html. I'm sure
their libraries provide more than plenty of support for what you may be
looking for.
Best regards
Michael
> -----Original Message-----
> From: Jeff Davis [mailto:jeff.davis@zetnet.co.uk]
> Sent: Wednesday, 22 November 2000 2:51
> To: Anders Rundgren; EKR
> Cc: PKIX-List
> Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols
> support XML
> well?
>
>
> Anders,
>
> From a potential user of the PKIX standards and a developer
> of software
> products we are currently using XML within our product suites for
> describing data and sending between various points etc. In
> about 6 to 8
> months we will be wanting to create PKCS#10 requests and
> receive PKCS#7
> responses etc in other product ventures (probably will also
> use many of
> the other PKCS#'s as well ).
>
> One of the skill bases we have is JAVA and XML. It would
> make sense to
> me to be able to do PKIXML in the future period and not have to either
> re-skill my development workforce/get new skill set in in order to
> process ASN-1/BER etc. (a selfish attitude maybe but when I asked them
> if anyone had knowledge of ASN-1, all I got was blank faces,
> it is a sad
> world! ) - tell me if I am missing something here that my JAVA
> programmers do not need to know the finer arts of ASN-1 to actual
> interface to it!.
>
> So, I for one would like to see a WG go forward so the PKIX
> does support
> XML. This would give people a choice in the future if it does
> transpire
> that XML can do the job, and as secure as present methods.
>
> Hope this does not conflict too much with the purists for
> PKIX standards
> as they have done/doing a great job. I just think that you
> now need to
> at least give XML a good hearing and this may be best served inside a
> WG.
>
> Jeff Davis
> SafeStone Technologies
> ( beginner in PKI )
>
> ----- Original Message -----
> From: Anders Rundgren <anders.rundgren@telia.com>
> To: EKR <ekr@rtfm.com>
> Cc: PKIX-List <ietf-pkix@imc.org>
> Sent: Tuesday, November 21, 2000 3:51 PM
> Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols
> support XML
> well?
>
>
> > > "Anders Rundgren" <anders.rundgren@telia.com> writes:
> > > > XMLDSIG i AFAIK a replacement for PKCS #7 and why did the IETF
> > > > bother with that? So far as I can see even Baltimore is pushing
> > > > (proprietary) XML-based security solutions.
> > > XMLDSIG is certainly not a replacement for PKCS-7. How could it
> > > be, since it does not provide for encryption?
> >
> > OK, I erred. XMLDSIG only replaces a _subset_ of PKCS #7. But it is
> definitely an example
> > of "PKI with XML-flavor"
> >
> > It would be of more interest to know your opinion on
> PKIXML, or should
> I interprete
> > your geekic comment as: PKI+XML is crap, so why bother?
> >
> > Anders
> >
> >
>
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA01655 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 20:12:26 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA04170; Wed, 22 Nov 2000 14:12:34 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <W0XV10B3>; Wed, 22 Nov 2000 15:03:47 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCAD8BF2D@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Peter Lipp <plippml@iaik.at>, EKR <ekr@rtfm.com>, Anders Rundgren <anders.rundgren@telia.com>
Cc: PKIX-List <ietf-pkix@imc.org>
Subject: RE: Scope of PKIXML-WG. Was: Should PKIX protocols support XML w ell?
Date: Wed, 22 Nov 2000 15:03:38 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Let me say that XMLDSIG is not a replacement for PKCS#7-signing either:
PKCS#7 is a general-purpose structure for signing data blobs. And XMLDSIG is
a format which was designed specifically to be 'native' for signing XML
documents.
As much as you wouldn't normally use PKCS#7 to sign XML documents today, you
wouldn't use XMLDSIG to sign a random binary data block. We are talking
practical use, of course, not a theory.
> -----Original Message-----
> From: Peter Lipp [mailto:plippml@iaik.at]
> Sent: Tuesday, 21 November 2000 18:06
> To: EKR; Anders Rundgren
> Cc: PKIX-List
> Subject: AW: Scope of PKIXML-WG. Was: Should PKIX protocols
> support XML
> well?
>
>
> Eric,
>
> >XMLDSIG is certainly not a replacement for PKCS-7. How could it
> >be, since it does not provide for encryption?
> Ok, let it be half a replacement and the other half currently
> being worked
> on in the XML-encryption-(list,WG?) - so what's the point...
>
> Peter
>
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA01026 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 19:55:32 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA04100; Wed, 22 Nov 2000 14:01:44 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <W0XV10B2>; Wed, 22 Nov 2000 14:52:57 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCAD8BF19@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Anders Rundgren <anders.rundgren@telia.com>, Michael Zolotarev <mzolotarev@baltimore.com>, Stephen Kent <kent@bbn.com>, Nada Kapidzic Cicovic <nada@entegrity.com>
Cc: PKIX-List <ietf-pkix@imc.org>
Subject: RE: Scope of PKIXML-WG. Was: Should PKIX protocols support XML w ell?
Date: Wed, 22 Nov 2000 14:52:51 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
All,
Before I start, I'd like to make my position clear: I accept the fact of
XML been popular. But I don't accept the fact that XML is superior for the
areas where ASN is currently used. So far, my two cents worth of the
discussion was entirely devoted to the attempts to see whether XML presents
a better choice *technically*. And so far, I'm still standing firm on my
original position. But let's forget about it for a moment.
****************************
<<Don't interpret what I'm about to say as a manifest of my personal, or
Baltimore's, support of it. It is just a position that I suggest might be
*considered* by the list, as an attempt to sort out the current 'crisis'
situation>>
****************************
I beleive that we have to come up with a solution too. Or at least to
outline how we can proceed to reach a solution before, or during the next
IETF meeting.
I would certainly hope that IETF is the right place to handle *this*. But
first we have to decide what exactly *this* is.
1. Transition to XML everywhere where currently ASN1 is used?
2. XML as an ASN1 replacement for *anything* new which has a PKI smell in
it?
3. XML as one of the languages of authorisation (and *probably*
authentication) frameworks?
(1): I don't think so. And we have already discussed and passed that point,
I hope.
(2): What such a WG would be concerned about? Defining
"XML-for-PKI-in-general, except 'core' PKI constructs"? Or concentrating on
every particular existing and future protocols, and explaining "in general"
how XML can be used there? Frankly, I don't think we'll get anywhere going
this way.
(3): We may develop a practical approach for a particular area. The approach
(and the mistakes we'll made on the way) can be utilised by the others in
the future, should other hi-level protocols decide to use XML too. Stop
mixing up with OCSPv2 /SCVP issues (they have to decide on the concept and
the use models first, before talking the actual encoding).
Let me elaborate on the (3):
WHAT: Activity. Not a WG.
WHERE: IETF AAA WG. I just think it'd be a right place for it. Outside of
PKIX, which maintains its purity and concentrates on core protocols and
structures. Not in W3C, which shouldn't be dealing with anything higher than
core XML (language, schemas, basic XML signing etc).
HOW: I can see two possible approaches here:
a) by doing it from scratch
b) by accommodating the work currently being done by vendor
consortiums.
Both (a) and (b) have cons and pros:
Doing it from scratch will be not so productive, considering that there is
something already been done. And the activity may be facing a huge
opposition by the vendors (which is happening already, mind you - didnt get
much traffic on the list from Netegrity and Co).
Letting the vendors to do the 'dirty work' first, and then 'donate' the
results to the IETF to finish the polishing up is probably the way to go.
Depends on their willingless to cooperate. We saw it happening in the past -
SSL/TLS is an example of a vendor-initiated standard. However, the earlier
IETF gets involved, the better.
What do we do now:
Agree on wheter we are talking (1), (2) or (3).
If we manage to agree that (3) is a viable option, I suggest we investigate
(a) and (b) immediately. By talking to all involved parties, the S2ML,
probably DirectoryForum, and try to do as much background work before San
Diego.
Opinions?
Michael
PS Good morning to everybody. I'm prepared to stay at work late tonight.
> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Tuesday, 21 November 2000 17:19
> To: Michael Zolotarev; Stephen Kent; Nada Kapidzic Cicovic
> Cc: PKIX-List
> Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols
> support XML
> well?
>
>
> Michael,
>
> Instead of fighting an impossible battle (which is best
> of...) we must handle this NOW.
>
> The following list which I got from Peter Lipp of IAIK shows
> what the options are:
>
> - that this was a stupid idea from the beginning and
> everybody involved
> should be ashamed
> - to have it as an activity which would be ideally placed within the
> PKIX-group (which is not really an option as Steven Kent and many
> others would not support it)
> - to have it as a new activity of the XML-DSig WG
> - to start a new WG within the IETF
> - to start a new WG within W3C
> - to start a new joint WG within W3C/IETF
>
> My definition of scope is "PKI with XML-flavor" i still valid
>
> > That's exactly what I'm afraid of - spending efforts and
> resources on
> > something which is purely market reasons-driven. There must
> be [at least a
> > fraction of] technical rationale behind it, not just an
> 'executive level
> > ability to comprehend'. And yes, of course I know that a
> lot of people don't
> > agree with it.
>
> If technical rationale has to involve superiority over ASN.1
> in _every_ technical respect
> it is a lost case. I consider the OID vs Schema to be a
> techical reason to switch to
> XML. You don't agree that this is valid. But that XML
> parsers will be a part of the OS is
> a hard fact to consider.
>
> XMLDSIG i AFAIK a replacement for PKCS #7 and why did the
> IETF bother with that?
> So far as I can see even Baltimore is pushing (proprietary) XML-based
> security solutions.
>
> That XML is becoming the "lingua franqua" in just about all
> sectors makes
> it a bit more interesting than a pure execetive level thing.
> And If XML works
> in e-commerce, banking, etc. it simply must work in PKI as
> well. I think that XMLDSIG
> actually proves everything we need to know at this stage.
>
> Anders
>
Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13049 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 13:54:06 -0800 (PST)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id <V9A7WPSS>; Tue, 21 Nov 2000 13:49:18 -0800
Message-ID: <1BE57AA01A5ED411866500B0D049657B42A561@exchange.cylink.com>
From: "Covey, Carlin" <ccovey@cylink.com>
To: "'Michael Myers'" <MMyers@verisign.com>, Denis Pinkas <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org
Subject: RE: DPV vs SCVP
Date: Tue, 21 Nov 2000 13:49:08 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
What is the incompatibility that is at issue here? I've done a character by
character
comparison of OCSP v1 and OCSP v2, and I don't see a problem.
I'm no ASN.1 whiz, but it looks like an OCSP v1 server would have no trouble
processing a basic v1 request from an OCSP v2 client, which in turn could
process an
OCSP v1 response perfectly well. (If the v2 client didn't know if the
server was
v1 or v2, it might make a v2 request first, get a "malformedRequest"
response and
then try a v1 request.) Likewise, an OCSP v2 server would have no problem
with a
request from an OCSP v1 client, and would simply return an OCSP v1 response.
Am I missing something?
Regards,
Carlin Covey
Cylink corp.
> -----Original Message-----
> From: Michael Myers [mailto:MMyers@verisign.com]
> Sent: Friday, November 17, 2000 12:59 PM
> To: Denis Pinkas
> Cc: ietf-pkix@imc.org
> Subject: RE: DPV vs SCVP
>
>
> Denis,
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > Sent: Friday, November 17, 2000 12:36 AM
> > To: Michael Myers
> > Cc: Paul Hoffman / IMC; ietf-pkix@imc.org
> > Subject: Re: DPV vs SCVP
> >
> >
> > Michael,
> >
> > > Paul,
> > >
> > > The OCSPv2 draft does not propose a new protocol; it's an
> > improvement to an
> > > existing protocol.
> >
> > Obviously wrong.
>
> This is what I was afraid of. I don't think it's productive
> to argue this
> point. What's important is determining if the proposals are
> technically
> correct and responsive to requirements.
>
> > In the current proposal, there is no backward
> > compatibility: OCSPv2 is a new protocol. The only big
> > advantage for OSCPv2
> > against SCVP would be some kind of backward compatibility
> with OCSPv1.
> > Otherwise, since SCVP is also a new protocol, why not
> > consider it (I mean
> > its ASN.1 version, not its XML version) ?
>
> I'm quite sure we're describing the same elephant.
>
> > Before going to this extreme
> > position, I would like to try to "save" OCSP, hence why I am
> > spending (too
> > much ?) energy on that topic.
>
> The question is, do we wish to address these issues and briefly cycle
> RFC2560 at proposed or simply address incremental corrections
> and move it
> forward? Rough consensus appears to favor the former.
>
> >
> > > At its core it proposes alternative means of identifying
> > > a certificate that are more in line with well-known needs.
> >
> > "Alternative", in this case, means different and thus
> > non-compatible means.
>
> The original v1 certID syntax is preserved in a backwards
> interoperable
> fashion. But this discussion has yielded the correct effect.
> It's clear I
> need to improve the draft more or less as follows as a
> proposal to the WG.
>
> v1 servers SHALL support certID to ensure interoperability
> with v1 clients.
>
> v2 clients SHOULD (SHALL?) be capable of supporting the
> original certID
> structure.
>
> >
> > > It could be argued that the DPV and DPD drafts define a new
> > protocol. But
> > > since (and especially in the case of DPV) we're talking
> > about little more
> > > than extension OIDs, I fear that we'll get so wrapped up
> > debating what is a
> > > protocol vs. a protocol extension that we'll lose sight of
> > the problem we're
> > > trying to solve.
> >
> > DPV and DPD can only be considered as extensions, if you
> > agree with the
> > meaning of the status I explained in two E-mails sent to you.
> > I am still
> > awaiting a detailed response from you on this matter, and
> > globally on my
> > previous E-mail.
>
> I had hoped that you considered my prior emails as
> responsive. Some of your
> comments I didn't take to be actionable in the absence of a broader
> consensus. I'll take another look at them today to see if I missed
> something obvious.
>
> >
> > > BTW, all 2560 authors were asked if they wished to
> > contribute at that same
> > > level of cycle time committment on OCSPv2. The authorship
> > list on the
> > > OCSPv2 draft reflects the outcome of those invitations.
> >
> > Not open to invitations for others ? Is it a closed user group ?
>
> Of course it's an open WG and as an IETF WG the technical
> contributions of
> its participating members are key to the quality of the
> solutions that we
> produce.
>
> >
> > > My response to Denis is simply me thinking that once we've
> > achieved rough
> > > consensus, running code and an RFC that the IETF has
> > spoken. Else when is a
> > > last call not a last call? When is rough consensus not
> > rough consensus?
> > > When is running code not running code? I look to the
> > chairs to provide us
> > > guidance on these points. Until then, that's my story and
> > I'm sticking to
> > > it.
> >
> > We are far from rough consensus at the time being.
>
> Actually, I believe we are.
>
> If what you're saying is, Denis' text wasn't recorded
> verbatim as proposed,
> well, that's probably true. Much of the text I propose isn't recorded
> verbatim either. But your comments nonetheless have yeilded
> positive impact
> on this technical improvement to an Internet standard. And
> after all, isn't
> that why we do what we do?
>
> > If you
> > continue to stick
> > on your positions, I will be inclined to agree with Paul: "
> > If the author of
> > a document is not willing to work within the IETF framework,
> > maybe it is
> > time for a different author or additional co-authors". We
> > need to move up.
>
> As I tried to say, I am doing all I can to fully enable the
> IETF process on
> this issue. This includes a healthy respect for the
> consensus development
> process. That in turn leads me to conclude that once a WG
> has gone through
> the pain of developing a consensus-based position, those
> efforts should be
> respected in the interests of maintaining our forward progress.
>
> And as I tried to say, I'm happy to be guided towards an alternative
> understanding. But it's my sense that once the IETF makes a
> decision that
> leads to an RFC, we should be very cautious in recanting on those
> recommendations. For example, some of my earliest OCSP
> drafts advocated for
> a non-ASN.1 syntax because doing so benefits development,
> debugging and
> deployment, as Khaja recently and so well put it. The WG
> decided that it
> wanted an ASN.1-based solution. We made that decision and moved on.
>
> It's my opinion that we must think through a reset of the "good" and
> "unknown" status responses very carefully because of what it
> implies upon
> the IETF process. It's possible however that my opinion is
> unique among
> IETF members. If so and knowning that, I look to the chairs
> for guidance to
> help me ensure that the IETF process is fully respected as we
> go forward on
> this obviously vital issue.
>
> >
> > Denis
>
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08784 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 11:52:07 -0800 (PST)
Received: from mega (t5o69p106.telia.com [213.64.110.106]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id UAA12667; Tue, 21 Nov 2000 20:50:21 +0100 (CET)
Message-ID: <00d801c053f4$162d7f60$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "EKR" <ekr@rtfm.com>, "Peter Lipp" <plippml@iaik.at>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <OEEELKIFKJHGADBKOFPNAEGNCBAA.plippml@iaik.at> <kjem05icqs.fsf@romeo.rtfm.com>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
Date: Tue, 21 Nov 2000 20:48:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA08789
Eric,
> I took it to be that XMLDSIG was evidence that the IETF intended
> to cook up a parallel cryptographic infrastructure based on XML.
> We may decide to do that now, but I think it's pretty clear that
> XMLDSIG was not intended as part of such an effort. If it had
> been, encryption would have been part of it, since encryption
> and DSIG are so clearly of a single piece: messaging.
I think that a major reason why XMLDSIG didn't "do it all" is that encryption has a
much, much lower priority for the sector that actually _screems_ for better
solutions. E-business and banking.
Such apps use TLS/SSL in 99.9% of all cases, and encrypted data would just
complicate things.
Anyway, IETF's involvement in XMLDSIG was pretty late and probably included
some "politics" as well so it may not be entirely valid of what the future will bring.
Nevertheless, XMLDSIG will probably be one of the most significant PKI-related
standards ever. Not far from the importance of PKCs and SSL.
Going back to the original question: Do you support the forming of a new PKIXML WG?
Anders
Received: from junker.ms.inka.de (xli.yapay.inka.de [212.227.14.169]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04553 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 10:43:47 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 5885A67C4E for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 10:18:19 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A1A3DD8.7F2558E1@stroeder.com>
Date: Tue, 21 Nov 2000 10:18:16 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <sa19023c.050@prv-mail20.provo.novell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bob Jueneman wrote:
>
> In another hypothetical case, an Enterprise may wish to institute
> a centralized control over which end-entities will be considered "trusted,"
> based in part on, but certainly not limited to the certificate validity
> status of the end-entity.
I consider this case to be an authorization issue in opposite to
just validate
the certificate itself. IMHO this is not the purpose of OCSP
although the protocol might seem handy for this.
RFC2560:
"1. Abstract
This document specifies a protocol useful in determining the
current
status of a digital certificate without requiring CRLs."
Maybe the term "status of a digital certificate" has to be better
defined in this discussion.
Ciao, Michael.
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02180 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 10:08:30 -0800 (PST)
Received: from certplus.com ([192.168.212.171]) by certplus.com (8.8.7/8.8.7) with ESMTP id TAA28693; Tue, 21 Nov 2000 19:13:06 +0100
Message-ID: <3A1AB9E3.683881AB@certplus.com>
Date: Tue, 21 Nov 2000 19:07:31 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Davis <jeff.davis@zetnet.co.uk>, ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
References: <D44EACB40164D311BEF00090274EDCCAD8B820@sydneymail1.jp.zergo.com.au> <001f01c0538b$46eed270$0201a8c0@vincent.se> <kjk89xixme.fsf@romeo.rtfm.com> <002901c053d2$fa39bf60$0201a8c0@vincent.se> <001201c053db$7e5e5af0$ee2cf7c2@zetnet.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jeff Davis wrote:
> From a potential user of the PKIX standards and a developer of software
> products we are currently using XML within our product suites for
> describing data and sending between various points etc. In about 6 to 8
> months we will be wanting to create PKCS#10 requests and receive PKCS#7
> responses etc in other product ventures (probably will also use many of
> the other PKCS#'s as well ).
>
> One of the skill bases we have is JAVA and XML. It would make sense to
> me to be able to do PKIXML in the future period and not have to either
> re-skill my development workforce/get new skill set in in order to
> process ASN-1/BER etc. (a selfish attitude maybe but when I asked them
> if anyone had knowledge of ASN-1, all I got was blank faces, it is a sad
> world! ) - tell me if I am missing something here that my JAVA
> programmers do not need to know the finer arts of ASN-1 to actual
> interface to it!.
Your JAVA programmer do not need to know the finer arts of ASN-1 to actual
interface to it.
Did you redevelop an XML interpreter from scratch in your software product ?
I don't believe so.
You just need a Java library that can be used to read the PKIX structures
and then interpret the content of the object, but not to understand the
finer details of ASN.1/DER.
I believe you will find this such a java toolkit in the Jonah library that's
available for free, but unfortunately doesn't seem to be as of now fully
available for export outside of america.
Probably other people here can give you the name of other products than can
be used for that.
This doesn't mean your programmer will not have to learn a lot of new
things.
They will have to understand what the content of this objects is, how they
behaves, concepts of PKI infrastructures.
But this is not because the transport layer uses ASN.1/DER.
It's because it will be a new environment for them, and it would be the same
if we reimplement everything in XML.
This said it might be that the PKIX environement lacks reasonnally priced,
properly documented !!! development environments.
I know several that are available for free, but which one has a
documentation that can compare to the one of any XML toolkit ?
Except for a commercial product that doesn't comply to the "reasonnally
priced" criterium.
Received: from irwell.zetnet.co.uk (root@irwell.zetnet.co.uk [194.247.47.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26334 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 08:55:02 -0800 (PST)
Received: from jeffdavis (man-a226.dialup.zetnet.co.uk [194.247.44.226]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA20088; Tue, 21 Nov 2000 16:54:27 GMT
X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a226.dialup.zetnet.co.uk [194.247.44.226] claimed to be jeffdavis
Message-ID: <001201c053db$7e5e5af0$ee2cf7c2@zetnet.co.uk>
From: "Jeff Davis" <jeff.davis@zetnet.co.uk>
To: "Anders Rundgren" <anders.rundgren@telia.com>, "EKR" <ekr@rtfm.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCAD8B820@sydneymail1.jp.zergo.com.au> <001f01c0538b$46eed270$0201a8c0@vincent.se> <kjk89xixme.fsf@romeo.rtfm.com> <002901c053d2$fa39bf60$0201a8c0@vincent.se>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
Date: Tue, 21 Nov 2000 16:51:10 -0000
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01C053DB.4025B490"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
This is a multi-part message in MIME format.
------=_NextPart_000_000E_01C053DB.4025B490
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Anders,
>From a potential user of the PKIX standards and a developer of software
products we are currently using XML within our product suites for
describing data and sending between various points etc. In about 6 to 8
months we will be wanting to create PKCS#10 requests and receive PKCS#7
responses etc in other product ventures (probably will also use many of
the other PKCS#'s as well ).
One of the skill bases we have is JAVA and XML. It would make sense to
me to be able to do PKIXML in the future period and not have to either
re-skill my development workforce/get new skill set in in order to
process ASN-1/BER etc. (a selfish attitude maybe but when I asked them
if anyone had knowledge of ASN-1, all I got was blank faces, it is a sad
world! ) - tell me if I am missing something here that my JAVA
programmers do not need to know the finer arts of ASN-1 to actual
interface to it!.
So, I for one would like to see a WG go forward so the PKIX does support
XML. This would give people a choice in the future if it does transpire
that XML can do the job, and as secure as present methods.
Hope this does not conflict too much with the purists for PKIX standards
as they have done/doing a great job. I just think that you now need to
at least give XML a good hearing and this may be best served inside a
WG.
Jeff Davis
SafeStone Technologies
( beginner in PKI )
----- Original Message -----
From: Anders Rundgren <anders.rundgren@telia.com>
To: EKR <ekr@rtfm.com>
Cc: PKIX-List <ietf-pkix@imc.org>
Sent: Tuesday, November 21, 2000 3:51 PM
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML
well?
> > "Anders Rundgren" <anders.rundgren@telia.com> writes:
> > > XMLDSIG i AFAIK a replacement for PKCS #7 and why did the IETF
> > > bother with that? So far as I can see even Baltimore is pushing
> > > (proprietary) XML-based security solutions.
> > XMLDSIG is certainly not a replacement for PKCS-7. How could it
> > be, since it does not provide for encryption?
>
> OK, I erred. XMLDSIG only replaces a _subset_ of PKCS #7. But it is
definitely an example
> of "PKI with XML-flavor"
>
> It would be of more interest to know your opinion on PKIXML, or should
I interprete
> your geekic comment as: PKI+XML is crap, so why bother?
>
> Anders
>
>
------=_NextPart_000_000E_01C053DB.4025B490
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwzCCAjww
ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ
BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs
aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea
BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg
1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm
lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z
SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4
RTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy
MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL
uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj
zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYw
RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
AgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/
LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDl
X4KmsaiSxVhqwY0DPOvDzQWikK5uMIIETTCCA7agAwIBAgIQat1MGeiCubKpRtmanUnH8TANBgkq
hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu
IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg
SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMDA0MjYw
MDAwMDBaFw0wMTA0MjYyMzU5NTlaMIIBFTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV
BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw
b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0
IEZ1bGwgU2VydmljZTETMBEGA1UEAxQKSmVmZiBEYXZpczEmMCQGCSqGSIb3DQEJARYXamVmZi5k
YXZpc0B6ZXRuZXQuY28udWswXDANBgkqhkiG9w0BAQEFAANLADBIAkEA3N/fjyGwWl7qRo9/AMUh
zTw4QHJcZYUAaOUNCPc8lrTkRzRzfxnXzKlFMiWZ8qXWRNn3ogrnz+ckfwSxvbWGqQIDAQABo4IB
JjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBwEIMCowKAYIKwYBBQUHAgEW
HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgB
hvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5
ZGE3NWJjNGJjOTcwMTc0N2RhNWMxZTMxNDFiZWFkYjJiZDI4YmU1MTdhYzZhOThiMDExNDk5Y2Ey
YjI0N2Y5ZjNlYTQ1MGQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v
Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQBIpsjsnaTekorJTnURkiZ6qlEao4J5cgKDbKW6
cA3CW2LXuZsugj5hQ/lUzYMjY6jSKiM7WquT3x33xVAnwbGuHl4GXeJdZWOGhetx0+BL4J8k7cJ4
zITXqBoF4TpTjN2H8KyicBeuRsO1KIW1JlQDksVI6xG6Ogg0pCcvhp4z0DGCAcYwggHCAgEBMIHh
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk
dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBq3UwZ6IK5sqlG2ZqdScfxMAkG
BSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDEx
MjExNjUxMTBaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJKoZIhvcNAQkEMRYE
FDpOe7jxtnum/7eE1iW7orikV8QHMA0GCSqGSIb3DQEBAQUABECA41MN52BfrUfc+nOpC2NNSOG0
bL4Sh7dE4YsZ/D6Af3CFU/z46NViXWBK9RI2PR1LcbiygVDf03rvzD4pA/9aAAAAAAAA
------=_NextPart_000_000E_01C053DB.4025B490--
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25274 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 08:27:21 -0800 (PST)
Received: from mega (t5o69p110.telia.com [213.64.110.110]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id RAA23179; Tue, 21 Nov 2000 17:28:00 +0100 (CET)
Message-ID: <004601c053d7$d1f60810$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>, <jis@mit.edu>, <mleech@nortelnetworks.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>, "Nada Kapidzic Cicovic" <nada@entegrity.com>, "Michael Zolotarev" <mzolotarev@baltimore.com>
References: <D44EACB40164D311BEF00090274EDCCAD8B820@sydneymail1.jp.zergo.com.au>
Subject: PKIXML-WG in San Diego. Action Required
Date: Tue, 21 Nov 2000 17:26:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA25275
Ladies and Gentlemen,
I think it would be improper to gather people from all over the globe without
putting the above subject on the aggenda.
I.e. those who _are_ interested must know which day this is going to be
discussed. There should be at least 2 hours of meeting time.
Or at least setup a PKIXML mailing-list.
Looking forward to a quick handling.
Best regards
Anders Rundgren
co-founder X-OBI
+46 70 - 627 74 37
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23394 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 07:55:06 -0800 (PST)
Received: from mega (t5o69p85.telia.com [213.64.110.85]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id QAA28608; Tue, 21 Nov 2000 16:53:21 +0100 (CET)
Message-ID: <002901c053d2$fa39bf60$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "EKR" <ekr@rtfm.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCAD8B820@sydneymail1.jp.zergo.com.au> <001f01c0538b$46eed270$0201a8c0@vincent.se> <kjk89xixme.fsf@romeo.rtfm.com>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
Date: Tue, 21 Nov 2000 16:51:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA23396
> "Anders Rundgren" <anders.rundgren@telia.com> writes:
> > XMLDSIG i AFAIK a replacement for PKCS #7 and why did the IETF
> > bother with that? So far as I can see even Baltimore is pushing
> > (proprietary) XML-based security solutions.
> XMLDSIG is certainly not a replacement for PKCS-7. How could it
> be, since it does not provide for encryption?
OK, I erred. XMLDSIG only replaces a _subset_ of PKCS #7. But it is definitely an example
of "PKI with XML-flavor"
It would be of more interest to know your opinion on PKIXML, or should I interprete
your geekic comment as: PKI+XML is crap, so why bother?
Anders
Received: from ns1.litenet.net (ns1.litenet.net [146.145.80.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA02959 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 04:11:10 -0800 (PST)
Received: from [146.145.80.87] by ns1.litenet.net (NTMail 4.30.0013/AF7530.63.6888ad76) with ESMTP id hctedaaa for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 00:48:22 -0500
X-Sender: martman37@excite.com
From: Marty Bradley <martman37@excite.com>
To: ietf-pkix@imc.org
Date: Wed, 22 Nov 2000 21:45:00 -0500
Subject: Money Making Discovery
Reply-To: martman37@excite.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <05482244112388@excite.com>
BIG News...
We have discovered a secret to generating a fortune
over the Internet and are looking for a few good
people to share it with. This is not an open
invitation for everyone...
I'm sorry, but if you're looking for overnight
wealth, this is not it... just the next best thing!
This could finally be your chance to get that brand
new car and go on that dream vacation you've always
wanted.
This is THE BIG ONE! So pay real close attention...
We found a multi-million dollar giant who will pay
you $1,000 every time you show someone how to take
an exotic vacation with less than $90 down. No
kidding!
There are people making 5-figure monthly incomes
doing this each and every month. Some of them are
doing it their very first month. We can show you
how to do this right from the comfort of your home
using no more than your computer and telephone.
Just reply to this email, and put MORE INFO in the
subject line, for details and a website that will
spill the beans on this remarkable venture.
Don't drag your feet on this one. It may be what
you have been looking for all your life. It's time
to take that dream vacation without spending a dime
out of your pocket.
Best regards,
The Support Team
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTE: You are not on any list. You received this
Email due to a past inquiry, or to a more recent
interest in a business opportunity. If you have
received this Email in error, then type REMOVE
in the subject header for no further contact.
***** WE HAVE A ZERO-TOLERANCE FOR SPAM! *****
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA07276 for <ietf-pkix@imc.org>; Tue, 21 Nov 2000 00:04:44 -0800 (PST)
Received: from plipp [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id ACC91FF00BC; Tue, 21 Nov 2000 09:05:29 +0100
From: "Peter Lipp" <plippml@iaik.at>
To: "EKR" <ekr@rtfm.com>, "Anders Rundgren" <anders.rundgren@telia.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
Subject: AW: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
Date: Tue, 21 Nov 2000 09:05:43 +0100
Message-ID: <OEEELKIFKJHGADBKOFPNAEGNCBAA.plippml@iaik.at>
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 IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <kjk89xixme.fsf@romeo.rtfm.com>
Eric,
>XMLDSIG is certainly not a replacement for PKCS-7. How could it
>be, since it does not provide for encryption?
Ok, let it be half a replacement and the other half currently being worked
on in the XML-encryption-(list,WG?) - so what's the point...
Peter
Received: from speedy.rtfm.com ([198.144.203.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01311 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 23:33:41 -0800 (PST)
Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by speedy.rtfm.com (8.9.1/8.6.4) with ESMTP id XAA10402; Mon, 20 Nov 2000 23:37:52 -0800 (PST)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id XAA21396; Mon, 20 Nov 2000 23:37:45 -0800 (PST)
Sender: ekr@rtfm.com
To: "Anders Rundgren" <anders.rundgren@telia.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
References: <D44EACB40164D311BEF00090274EDCCAD8B820@sydneymail1.jp.zergo.com.au> <001f01c0538b$46eed270$0201a8c0@vincent.se>
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <ekr@rtfm.com>
Date: 20 Nov 2000 23:37:45 -0800
In-Reply-To: "Anders Rundgren"'s message of "Tue, 21 Nov 2000 08:18:39 +0100"
Message-ID: <kjk89xixme.fsf@romeo.rtfm.com>
Lines: 8
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
"Anders Rundgren" <anders.rundgren@telia.com> writes:
> XMLDSIG i AFAIK a replacement for PKCS #7 and why did the IETF
> bother with that? So far as I can see even Baltimore is pushing
> (proprietary) XML-based security solutions.
XMLDSIG is certainly not a replacement for PKCS-7. How could it
be, since it does not provide for encryption?
-Ekr
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA28202 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 23:19:27 -0800 (PST)
Received: from mega (t1o69p89.telia.com [62.20.144.89]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id IAA02472; Tue, 21 Nov 2000 08:20:05 +0100 (CET)
Message-ID: <001f01c0538b$46eed270$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Michael Zolotarev" <mzolotarev@baltimore.com>, "Stephen Kent" <kent@bbn.com>, "Nada Kapidzic Cicovic" <nada@entegrity.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCAD8B820@sydneymail1.jp.zergo.com.au>
Subject: Re: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
Date: Tue, 21 Nov 2000 08:18:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA28203
Michael,
Instead of fighting an impossible battle (which is best of...) we must handle this NOW.
The following list which I got from Peter Lipp of IAIK shows what the options are:
- that this was a stupid idea from the beginning and everybody involved
should be ashamed
- to have it as an activity which would be ideally placed within the
PKIX-group (which is not really an option as Steven Kent and many
others would not support it)
- to have it as a new activity of the XML-DSig WG
- to start a new WG within the IETF
- to start a new WG within W3C
- to start a new joint WG within W3C/IETF
My definition of scope is "PKI with XML-flavor" i still valid
> That's exactly what I'm afraid of - spending efforts and resources on
> something which is purely market reasons-driven. There must be [at least a
> fraction of] technical rationale behind it, not just an 'executive level
> ability to comprehend'. And yes, of course I know that a lot of people don't
> agree with it.
If technical rationale has to involve superiority over ASN.1 in _every_ technical respect
it is a lost case. I consider the OID vs Schema to be a techical reason to switch to
XML. You don't agree that this is valid. But that XML parsers will be a part of the OS is
a hard fact to consider.
XMLDSIG i AFAIK a replacement for PKCS #7 and why did the IETF bother with that?
So far as I can see even Baltimore is pushing (proprietary) XML-based
security solutions.
That XML is becoming the "lingua franqua" in just about all sectors makes
it a bit more interesting than a pure execetive level thing. And If XML works
in e-commerce, banking, etc. it simply must work in PKI as well. I think that XMLDSIG
actually proves everything we need to know at this stage.
Anders
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20233 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 21:07:37 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4C00C01ZLZFZ@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 20 Nov 2000 21:08:23 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4C00B7KZLZZW@ext-mail.valicert.com>; Mon, 20 Nov 2000 21:08:23 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <XDY1ZX8H>; Mon, 20 Nov 2000 21:06:10 -0800
Content-return: allowed
Date: Mon, 20 Nov 2000 21:06:02 -0800
From: Frank Balluffi <frankb@valicert.com>
Subject: RE: OCSP identifiers
To: Ambarish Malpani <ambarish@valicert.com>, "'Bland, Graham'" <Graham.Bland@open-talk.co.uk>, "'Simon Tardell'" <simon.tardell@smarttrust.com>, ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E13669E@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Also, a relying party may want to be able to prove that it performed a
certain amount of due diligence, which might include asking a validation
server certain questions.
Frank
> -----Original Message-----
> From: Ambarish Malpani [mailto:ambarish@valicert.com]
> Sent: Monday, November 20, 2000 11:53 AM
> To: 'Bland, Graham'; 'Simon Tardell'; ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
>
>
> Hi Graham,
> Not quite true. There are a bunch of cases, where a root CA
> certifies subCAs OCSP responders directly, whose status needs to
> be checked by looking up the cert with the root's OCSP responder
> (in practice, this second lookup gets optimized out).
>
> Anyway, there are real life models, where a responder is trusted
> because of a cert issued by a CA, but not necessarily trusted for
> that CA. So it is possible to want to revoke an OCSP responder's
> certificate.
>
> Regarding CRLs - these are (as Simon said) a great way of getting
> a snapshot of the statuses a CA has assigned. Also, by having CAs
> produce and publish new CRLs as soon as there is a revocation event,
> this becomes a great way of passing revocation data from a CA to
> a responder.
>
> CRLs are not scalable where they need to be distributed to a
> large number
> of clients [read thousands/hundreds of thousands]. They are a
> perfectly
> good way of distributing revocation data to a single client (the
> responder), which can then take on the responsibility of:
> a. Replicating to other responders
> b. Providing OCSP responses to a large number of clients.
>
> Also, there are real deployments where a person normally
> wants to revoke at
> the CA, but desires to, as an emergency action, suspend
> directly at the
> responder - so the responder uses both the CA's data (its
> CRL) and its own
> local database to see what the status of a certificate is.
>
> Hopefully, this helps explain the benefits of using CRLs and
> OCSP together.
>
> Regards,
> Ambarish
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect 650.567.5457
> ValiCert, Inc. ambarish@valicert.com
> 339 N. Bernardo Ave. http://www.valicert.com
> Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: Bland, Graham [mailto:Graham.Bland@open-talk.co.uk]
> > Sent: Monday, November 20, 2000 8:09 AM
> > To: 'Simon Tardell'; ietf-pkix@imc.org
> > Subject: RE: OCSP identifiers
> >
> >
> > Simon,
> >
> > Sorry but there are still some practical caveats to be applied here.
> >
> > If the OCSP responder is independent of the CA in question
> > then trust is
> > entirely between the requestor and the responder, in this
> > case the issuer
> > has no knowledge of nor involvement in the trust and cannot
> > invalidate the
> > responder in any way.
>
> Agreed.
>
> >
> > In the second case where the responder is a logical part of
> the CA in
> > question, the OCSP response is signed with the certificate
> > issuing key.
> > The only way the CA can invalidate the responder is by
> > revoking its own
> > issuing key which effectively requires a reconfiguration of
> > the requestor as
> > the CA key would have to be implicitly trusted. Practically
> > in this case
> > the CA can simply shut down the responder. I cannot see a
> > case where the CA
> > would allow the use of its key and not have this level of control.
>
> Agreed.
>
> >
> > The third case is where the responder is a CA designated
> > responder with a
> > specially marked certificate directly issued by the CA.
> > In this case the logistics of the process do not make sense.
> > Assuming the responder is being used to either:
> > 1. provide a more timely response than CRLs
> > 2. avoid having to manage the retrieval of CRLs
> >
> > In order to validate the OCSP response I must now either
> > retrieve a CRL or
> > Authority Information access (OCSP?) in order to validate the
> > response. If
> > the CRL is required then apart from a possible size reduction
> > in the CRL I
> > have to implement all the logic required to have verified the
> > certificates
> > status myself reducing the value of 2. Using a CRL here may
> > not satisfy the
> > timeliness required by 1. If Authority Information Access is
> > specified then
> > I have just entered a loop (assuming this specifies an OCSP
> > responder which
> > I then have to verify)
> >
> > So practically it is very difficult for a CA to invalidate an
> > OCSP responder
> > apart from by shutting it down, I would guess that
> > specifically trusted
> > responders or directly CA owned responders (which are
> > effectively implicitly
> > trusted) are the only practical methods that can be used.
> > (unless anybody
> > else has any other methods)
> >
> >
> > Graham Bland
> >
> >
> >
> >
> > -----Original Message-----
> > From: Simon Tardell [mailto:simon.tardell@smarttrust.com]
> > Sent: 20 November 2000 15:16
> > To: 'Bland, Graham'; Simon Tardell; ietf-pkix@imc.org
> > Subject: RE: OCSP identifiers
> >
> >
> > > Simon,
> > >
> > > There is no requirement
> >
> > Retracted. I don't know why I wrote that. It's Monday, I suppose.
> >
> > The point that I'd like to make though, is that there
> certainly is no
> > trouble deriving trust in the responder from trust of the
> > issuer (that is,
> > the issuer can invalidate the responder if it feels like).
> >
> > Simon.
> >
> > Simon Tardell, Software Architect, SmartTrust
> > voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
> > simon.tardell@smarttrust.com, http://www.smarttrust.com
> > ______________________________________________________________
> > _________
> >
> > This message is confidential and is intended for the addressee only;
> > unless clearly stated that this disclaimer should not apply, this
> > e-mail is not intended to create legally binding commitments on
> > behalf of any company in the British Interactive Broadcasting
> > Holdings Limited group, nor do its contents reflect the corporate
> > views or policies of any such company. Any unauthorised disclosure,
> > use or dissemination, either whole or partial, is
> prohibited. If you
> > are not the intended recipient of the message, please notify the
> > sender immediately.
> > ______________________________________________________________
> > _________
> >
>
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16546 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 16:39:27 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA26822; Tue, 21 Nov 2000 10:45:03 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <W0XV19BC>; Tue, 21 Nov 2000 11:36:10 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCAD8B820@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Anders Rundgren <anders.rundgren@telia.com>, Michael Zolotarev <mzolotarev@baltimore.com>, Stephen Kent <kent@bbn.com>, Nada Kapidzic Cicovic <nada@entegrity.com>, jis@mit.edu, mleech@nortelnetworks.com
Cc: PKIX-List <ietf-pkix@imc.org>
Subject: RE: Scope of PKIXML-WG. Was: Should PKIX protocols support XML w ell?
Date: Tue, 21 Nov 2000 11:36:10 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
>
> For a company like yours (Entegrity), it could be important
> to actually jump on the
> XML PKI bandwagon if only for marketing reasons. I guess you
> saw that Warwick
> Ford of VeriSign supported a variant of XML ACs (S2ML).
>
That's exactly what I'm afraid of - spending efforts and resources on
something which is purely market reasons-driven. There must be [at least a
fraction of] technical rationale behind it, not just an 'executive level
ability to comprehend'. And yes, of course I know that a lot of people don't
agree with it.
On a side note: within boundaries of what meant to be a vendor-neutral
technical discussion, it is just not very ..ehm... right, to rush people
into something by saying "if you don't, your competitors will". Nobody has
ever proven that XML authorisation will be [more] successful than ASN. The
fact that some vendors have got together for something does not necessarily
mean a red alert for the rest of the vendors. Something to keep an eye on -
sure.
We all can read in between the lines - you don't have to be that specific,
Anders :).
Regards
M
Received: from mailmc.ec.com.cn ([210.25.6.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16238 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 16:14:04 -0800 (PST)
From: yezhen@ec.com.cn
Received: from localhost (root@localhost) by mailmc.ec.com.cn (8.9.3 (PHNE_18979)/8.9.3) with SMTP id IAA22878 for ietf-pkix@imc.org; Tue, 21 Nov 2000 08:03:14 +0800 (EAT)
X-OpenMail-Hops: 1
Date: Tue, 21 Nov 2000 08:02:54 +0800
Message-Id: <H000018200d5fd64@MHS>
Subject: unsubscribe
MIME-Version: 1.0
TO: ietf-pkix@imc.org
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA05004 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 11:04:03 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 20 Nov 2000 12:04:08 -0700
Message-Id: <sa191338.039@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 20 Nov 2000 12:04:04 -0700
From: "Bob Jueneman" <bjueneman@novell.com>
To: <rsalz@caveosystems.com>, <chokhani@cygnacom.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: OCSP identifiers
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA05005
Hi, Santosh,
I was not commenting on the validity or inventiveness of the Micali patent overall, as I haven't read it, but only the existence of prior art relative to claim 37, and by implication claim 38 as posted by Rich.
As I believe the original series of messages made clear, timestamping the message is primarily of value in establishing a correlation with absolute time that can be used at some time in the future.
Most of the time, it would be sufficient to answer the question "Is the certificate corresponding the digital signature on this message currently valid?" If the answer is yes, then the message should be considered validly signed, since it was obviously signed prior to the request, and certificates are not allowed to revert back to valid from invalid.
If, however, the question was something along the lines of , "Was this digitally post-marked ballot received prior to the closing of the polls at 8:00PM EST, November 7, 2000, AND was the certificate valid at that time?", then a trusted-timestamp would be required.
The thrust of the 1993 argument was to get away from all of the time notarizing of both the message and the certificates, and the correlation of those events after the fact, by asking the CA to provide a real-time, authoritative response.
Micali may well have a clever scheme for solving some other problem, but the issue concerned including a certificate in a response from a responder that confirm the validity of a certificate (or by implication a signature). To that extent, I believe that claim 37 is overly broad and invalid, as it involves prior art and is not specifically related to the rest of the patent, i.e., the hashing scheme you described. And since I believe claim 37 should be rejected, the particular instance of 37 that is claimed by 38 should be rejected as well, as being obvious to those skilled in the art.
Bob
>>> Santosh Chokhani <chokhani@cygnacom.com> 11/20/00 11:35AM >>>
Bob:
Micali scheme is quiet simply and nifty. I am not a patent attorney either.
It could be considered an improvement since he does not time stamp the hash.
The Micali scheme works as follows. Let us say that n CRLs will be issued
during the life of the certificate (generally n = life/(CRL periodicity)).
The CA generates two random numbers and hashes them n times and puts them in
a certificate. One number is the good certificate number and the other is
revoked number. Each time it is time to update the revocation information
for a certificate, if the certificate is still good, the random number is
hashed one less time and the hash is sent to the directory. The relying
party can forward hash this to determine the certificate is good. If the
certificate is revoked, the revocation number is hashed fewer times and
relying party can determine the certificate is revoked.
I generally do not recommend, Micali scheme for the following reasons:
1. It is patented
2. It only provides information for one certificate. You are likely to
communicate with several folks in a CA's subscriber population.
3. For each user, you may need to get the revocation information and
perform directory bind.
I think CRL size is of concern in band-width challenged environment. But,
when a user is sitting on a 10mb/sec LAN, number of directory binds may be
the limiting factors.
-----Original Message-----
From: Bob Jueneman [mailto:bjueneman@novell.com]
Sent: Monday, November 20, 2000 12:32 PM
To: rsalz@caveosystems.com
Cc: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
Has anyone looked into challenging the validity of that patent? I think a
pretty good case could be made for prior art.
In a series of messages on the pem-dev list in September and October 1993 --
a full three years before Micali's patent was filed -- I discussed at
considerable length some of the problems with CRLs in a commercial
environment. On 9/21/93 I first discussed the possibility of a delta-CRL
mechanism, and then went on to examine the possibility of a positive
response system. On 9/22 I proposed requiring the CA to operate a trusted
time-stamping service so that the CA could sign the message digest of a
particular message in order to confirm that the certificate corresponding to
the digital signature of the message in question was valid at the time of
receipt.
I'm not a patent lawyer, but if I were one, I believe that I could
convincingly argue that the method I proposed in 1993 provides well-known
prior art that satisfies and hence invalidates Micali's claim 37. Depending
on how claim 38 is interpreted, the CA-authenticated certificate is either
the certificate of what we would now call the OCSP responder itself, or the
certificate that the OCSP responder is validating; but in either case the
possibility of including such a certificate in the response, if required for
some purpose, would certainly be obvious to anyone skilled in the art.
Regards,
Bob
Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.
>>> Rich Salz <rsalz@caveosystems.com> 11/17/00 08:27PM >>>
> You can't get much simpler than a list of cert hashes and a status
value...
If you want the OCSP responder to be able to work *only* off CRL's (e.g.,
Valicert -- arguably the OCSP market leader), then cert hash isn't very
useful.
> Probably the easiest option for everyone is to allow the pKCert ...
In a previous message I said that during work at a previous employer we
determined that this violates a patent by Micali. I held my nose and did
some
searches this evening, and I believe I found it. Claims 37ff of US Patent
5,717,757 filed Nov 96 and issued Feb 98:
37. A method for providing authenticated information about
certificates,
comprising the steps of:
(a) receiving a request for information about a certificate
including
a proof that the certificate is issued;
(b) verifying that the proof is valid; and
(c) in response to the proof being valid, providing the requested
information.
38. A method according to claim 37, wherein the proof includes
providing
an entire CA-authenticated certificate.
enjoy.
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03669 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 10:40:17 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <W5KZLGX7>; Mon, 20 Nov 2000 13:41:30 -0500
Message-ID: <8D7EC1912E25D411A32100D0B76953973E5120@scygmxs01.cygnacom.com>
From: Santosh Chokhani <chokhani@cygnacom.com>
To: Bob Jueneman <bjueneman@novell.com>, rsalz@caveosystems.com
Cc: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Mon, 20 Nov 2000 13:35:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05320.9D86A600"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C05320.9D86A600
Content-Type: text/plain;
charset="iso-8859-1"
Bob:
Micali scheme is quiet simply and nifty. I am not a patent attorney either.
It could be considered an improvement since he does not time stamp the hash.
The Micali scheme works as follows. Let us say that n CRLs will be issued
during the life of the certificate (generally n = life/(CRL periodicity)).
The CA generates two random numbers and hashes them n times and puts them in
a certificate. One number is the good certificate number and the other is
revoked number. Each time it is time to update the revocation information
for a certificate, if the certificate is still good, the random number is
hashed one less time and the hash is sent to the directory. The relying
party can forward hash this to determine the certificate is good. If the
certificate is revoked, the revocation number is hashed fewer times and
relying party can determine the certificate is revoked.
I generally do not recommend, Micali scheme for the following reasons:
1. It is patented
2. It only provides information for one certificate. You are likely to
communicate with several folks in a CA's subscriber population.
3. For each user, you may need to get the revocation information and
perform directory bind.
I think CRL size is of concern in band-width challenged environment. But,
when a user is sitting on a 10mb/sec LAN, number of directory binds may be
the limiting factors.
-----Original Message-----
From: Bob Jueneman [mailto:bjueneman@novell.com]
Sent: Monday, November 20, 2000 12:32 PM
To: rsalz@caveosystems.com
Cc: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
Has anyone looked into challenging the validity of that patent? I think a
pretty good case could be made for prior art.
In a series of messages on the pem-dev list in September and October 1993 --
a full three years before Micali's patent was filed -- I discussed at
considerable length some of the problems with CRLs in a commercial
environment. On 9/21/93 I first discussed the possibility of a delta-CRL
mechanism, and then went on to examine the possibility of a positive
response system. On 9/22 I proposed requiring the CA to operate a trusted
time-stamping service so that the CA could sign the message digest of a
particular message in order to confirm that the certificate corresponding to
the digital signature of the message in question was valid at the time of
receipt.
I'm not a patent lawyer, but if I were one, I believe that I could
convincingly argue that the method I proposed in 1993 provides well-known
prior art that satisfies and hence invalidates Micali's claim 37. Depending
on how claim 38 is interpreted, the CA-authenticated certificate is either
the certificate of what we would now call the OCSP responder itself, or the
certificate that the OCSP responder is validating; but in either case the
possibility of including such a certificate in the response, if required for
some purpose, would certainly be obvious to anyone skilled in the art.
Regards,
Bob
Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.
>>> Rich Salz <rsalz@caveosystems.com> 11/17/00 08:27PM >>>
> You can't get much simpler than a list of cert hashes and a status
value...
If you want the OCSP responder to be able to work *only* off CRL's (e.g.,
Valicert -- arguably the OCSP market leader), then cert hash isn't very
useful.
> Probably the easiest option for everyone is to allow the pKCert ...
In a previous message I said that during work at a previous employer we
determined that this violates a patent by Micali. I held my nose and did
some
searches this evening, and I believe I found it. Claims 37ff of US Patent
5,717,757 filed Nov 96 and issued Feb 98:
37. A method for providing authenticated information about
certificates,
comprising the steps of:
(a) receiving a request for information about a certificate
including
a proof that the certificate is issued;
(b) verifying that the proof is valid; and
(c) in response to the proof being valid, providing the requested
information.
38. A method according to claim 37, wherein the proof includes
providing
an entire CA-authenticated certificate.
enjoy.
------_=_NextPart_001_01C05320.9D86A600
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: OCSP identifiers</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Bob:</FONT>
</P>
<P><FONT SIZE=3D2>Micali scheme is quiet simply and nifty. I am not a =
patent attorney either. It could be considered an improvement =
since he does not time stamp the hash.</FONT></P>
<P><FONT SIZE=3D2>The Micali scheme works as follows. Let us say =
that n CRLs will be issued during the life of the certificate =
(generally n =3D life/(CRL periodicity)). The CA generates two =
random numbers and hashes them n times and puts them in a =
certificate. One number is the good certificate number and the =
other is revoked number. Each time it is time to update the =
revocation information for a certificate, if the certificate is still =
good, the random number is hashed one less time and the hash is sent to =
the directory. The relying party can forward hash this to =
determine the certificate is good. If the certificate is revoked, =
the revocation number is hashed fewer times and relying party can =
determine the certificate is revoked.</FONT></P>
<P><FONT SIZE=3D2>I generally do not recommend, Micali scheme for the =
following reasons:</FONT>
</P>
<P><FONT SIZE=3D2>1. It is patented</FONT>
<BR><FONT SIZE=3D2>2. It only provides information for one =
certificate. You are likely to communicate with several folks in =
a CA's subscriber population.</FONT></P>
<P><FONT SIZE=3D2>3. For each user, you may need to get the =
revocation information and perform directory bind.</FONT>
</P>
<P><FONT SIZE=3D2>I think CRL size is of concern in band-width =
challenged environment. But, when a user is sitting on a 10mb/sec =
LAN, number of directory binds may be the limiting factors.</FONT></P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Bob Jueneman [<A =
HREF=3D"mailto:bjueneman@novell.com">mailto:bjueneman@novell.com</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Monday, November 20, 2000 12:32 PM</FONT>
<BR><FONT SIZE=3D2>To: rsalz@caveosystems.com</FONT>
<BR><FONT SIZE=3D2>Cc: ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: OCSP identifiers</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Has anyone looked into challenging the validity of =
that patent? I think a pretty good case could be made for prior =
art. </FONT></P>
<P><FONT SIZE=3D2>In a series of messages on the pem-dev list in =
September and October 1993 -- a full three years before Micali's patent =
was filed -- I discussed at considerable length some of the problems =
with CRLs in a commercial environment. On 9/21/93 I first =
discussed the possibility of a delta-CRL mechanism, and then went on to =
examine the possibility of a positive response system. On 9/22 I =
proposed requiring the CA to operate a trusted time-stamping service so =
that the CA could sign the message digest of a particular message in =
order to confirm that the certificate corresponding to the digital =
signature of the message in question was valid at the time of =
receipt.</FONT></P>
<P><FONT SIZE=3D2>I'm not a patent lawyer, but if I were one, I believe =
that I could convincingly argue that the method I proposed in 1993 =
provides well-known prior art that satisfies and hence invalidates =
Micali's claim 37. Depending on how claim 38 is interpreted, the =
CA-authenticated certificate is either the certificate of what we would =
now call the OCSP responder itself, or the certificate that the OCSP =
responder is validating; but in either case the possibility of =
including such a certificate in the response, if required for some =
purpose, would certainly be obvious to anyone skilled in the =
art.</FONT></P>
<P><FONT SIZE=3D2>Regards,</FONT>
</P>
<P><FONT SIZE=3D2>Bob</FONT>
</P>
<P><FONT SIZE=3D2>Robert R. Jueneman</FONT>
<BR><FONT SIZE=3D2>Security Architect</FONT>
<BR><FONT SIZE=3D2>Novell, Inc. -- the leading provider of Net services =
software.</FONT>
</P>
<P><FONT SIZE=3D2>>>> Rich Salz <rsalz@caveosystems.com> =
11/17/00 08:27PM >>></FONT>
<BR><FONT SIZE=3D2>> You can't get much simpler than a list of cert =
hashes and a status value...</FONT>
</P>
<P><FONT SIZE=3D2>If you want the OCSP responder to be able to work =
*only* off CRL's (e.g.,</FONT>
<BR><FONT SIZE=3D2>Valicert -- arguably the OCSP market leader), then =
cert hash isn't very</FONT>
<BR><FONT SIZE=3D2>useful.</FONT>
</P>
<P><FONT SIZE=3D2>> Probably the easiest option for everyone is to =
allow the pKCert ...</FONT>
</P>
<P><FONT SIZE=3D2>In a previous message I said that during work at a =
previous employer we</FONT>
<BR><FONT SIZE=3D2>determined that this violates a patent by =
Micali. I held my nose and did some</FONT>
<BR><FONT SIZE=3D2>searches this evening, and I believe I found =
it. Claims 37ff of US Patent</FONT>
<BR><FONT SIZE=3D2>5,717,757 filed Nov 96 and issued Feb 98:</FONT>
<BR> <FONT SIZE=3D2>37. A =
method for providing authenticated information about =
certificates,</FONT>
<BR> <FONT =
SIZE=3D2>comprising the steps of: </FONT>
<BR> <FONT SIZE=3D2>(a) =
receiving a request for information about a certificate =
including</FONT>
<BR> <FONT =
SIZE=3D2> a proof that the certificate is =
issued;</FONT>
<BR> <FONT SIZE=3D2>(b) =
verifying that the proof is valid; and</FONT>
<BR> <FONT SIZE=3D2>(c) in =
response to the proof being valid, providing the requested</FONT>
<BR> <FONT =
SIZE=3D2> information. </FONT>
<BR> <FONT SIZE=3D2>38. A =
method according to claim 37, wherein the proof includes =
providing</FONT>
<BR> <FONT SIZE=3D2>an entire =
CA-authenticated certificate. </FONT>
</P>
<P><FONT SIZE=3D2>enjoy.</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C05320.9D86A600--
Received: from pierce.llnl.gov (pierce.llnl.gov [128.115.41.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01149 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 09:58:32 -0800 (PST)
Received: from painhouse.llnl.gov (painhouse.llnl.gov [128.115.54.70]) by pierce.llnl.gov (8.8.8/LLNL-3.0.2/llnl.gov-5.1) with ESMTP id JAA18092 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 09:58:48 -0800 (PST)
Message-Id: <5.0.0.25.2.20001120095946.0227f010@popsicle.llnl.gov>
X-Sender: e708550@popsicle.llnl.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 20 Nov 2000 10:00:25 -0800
To: ietf-pkix@imc.org
From: "Frank W. Ploof" <ploof1@llnl.gov>
Subject: unsubscribe
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_5471537==_.ALT"
--=====================_5471537==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Frank W. Ploof Entrust Ready
PKI Project Lead
Lawrence Livermore National Laboratory
Livermore, Ca. 94551
Ph. 925-422-6990
--=====================_5471537==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<br>
<x-sigsep><p></x-sigsep>
<font size=3>Frank W.
Ploof
</font><font size=3 color="#0000FF">Entrust Ready<br>
</font><font size=3>PKI Project Lead<br>
Lawrence Livermore National Laboratory<br>
Livermore, Ca. 94551<br>
Ph. 925-422-6990<br>
</font></html>
--=====================_5471537==_.ALT--
Received: from spoon.alink.net (spoon.alink.net [207.135.127.97]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01045 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 09:56:42 -0800 (PST)
Received: from oblix.com (athos.oblix.com [216.200.223.239]) by spoon.alink.net (8.9.3/8.9.3) with ESMTP id JAA07499 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 09:57:28 -0800 (PST)
Message-ID: <3A196632.79C1C8C9@oblix.com>
Date: Mon, 20 Nov 2000 09:58:10 -0800
From: Kaijin Gu <kgu@oblix.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Subscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subscribe
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA00465 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 09:51:29 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 20 Nov 2000 10:51:40 -0700
Message-Id: <sa19023c.050@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 20 Nov 2000 10:51:36 -0700
From: "Bob Jueneman" <bjueneman@novell.com>
To: <chokhani@cygnacom.com>, <ietf-pkix@imc.org>
Subject: RE: OCSP identifiers
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA00466
Santosh is quite correct -- there are situations which favor the use of CRLs, and there are situations which favor an on-line responder mechanism, and there are some interesting possibilities involving a blending of the two functions.
Consider the case where there is very limited bandwidth available from a given installation or community of interest back to the CA or the potential OCSP responder. For example, take a carrier battle group at sea, perhaps during wartime.
Depending on the emissions security rules in effect at the time, it is quite possible that the bandwidth back to a shore-based facility might be zero -- no communications are allowed at all. Yet satellite-based CRL reception might very well be feasible, and in particular a delta-CRL approach.
In this case, a local OCSP responder and/or a directory containing CRLs may be the most efficient way to distributing certificate validity information onboard the individual ships, and the choice of OCSP vs. locally distributed CRLs can be made based on the requirements of the information consumers.
In another hypothetical case, an Enterprise may wish to institute a centralized control over which end-entities will be considered "trusted," based in part on, but certainly not limited to the certificate validity status of the end-entity. For example, a hospital might not care what VeriSign thinks about the certificate validity of say Dr. Kevorkian -- the hospital may decide to reject any digitally signed orders, access control requests, etc., based on their own criteria.
In that case again, the responder can be anyone whom the RP trusts to make those decisions, either voluntarily or by edict.
Bob
>>> Santosh Chokhani <chokhani@cygnacom.com> 11/20/00 09:57AM >>>
Ambarish:
I do not mean to get in the middle of the debate. The issues in
architecting a solution for revocation information notification to relying
party are very complex and require consideration of topics such as:
v The communication model, i.e., which class of users are communicating with
which class of users. For example, if a user communicates with several
users who are subscriber to the same CA, a single CRL from the CA will
provide lot of relevant information and the user. On the other hand, if a
user is communicating with several users, all belonging to different CA,
each CRL is offering only information relevant to one user.
v The directory architecture in terms of where they are located and what
portions of the directory information is replicated and/or shadowed.
v The communication band-width available.
v The bind time to access the repository
v Size of the revocation response from the repository, e.g. CRL size
v Processing load on the repository, specially for digital signature
generation on the revocation information
v Processing load on the user workstation, specially for digital signature
verification on the revocation information
OCSP suffers from the following drawbacks:
v Since the revocation information is produced at the server, the
communication channel between the relying party and the server must be
secured, most likely by using digital signatures
v Signed operations will limit server scaleability since digital signature
generation is computationally intensive
v Since the revocation information is produced at the server, the scheme
requires a trusted server as opposed to an untrusted repository
v Revocation of server public key requires a method for checking server
public key status. This method is likely to be using the server public key
as an additional trust anchor or relying on a CRL mechanism.
v There needs to be non-suppressable mechanism for the CA to provide
revocation information to the trusted server
v There are no standards in the area of CA to provide non-suppressable
mechanism(s) for the revocation information to the trusted server
>From my experience, the most scaleable and versatile revocation notification
means can be achieved by using a combination of the following:
v Use of CRL
v Replication of CA directory entry for fast access to CRL
v Use of ARL
v Consolidation of ARL for all CAs in a domain through the use of
Distribution Points
v Consolidation of all the reason codes of key compromise for all
certificates in domain through the use of Distribution Point extension.
This CRL can be issued very frequently to meet the freshness requirements of
the domain. This mechanism makes the CRL mechanism as current as the OCSP
v Partitioning routine revocation information using Distribution Point CRL
if CRLs become too large
There are several other factors that can help improve the CRL retrieval
efficiency. These include:
v Repositories require the encoded CRL to send to the relying parties. The
repositories also require decoded CRL to perform searches. It may desirable
for the repository to store both encoded and decoded form as opposed to
performing encoding or decoding for each request
v Bind operation to repository can be slow if authentication is required.
If the repository does not store any private information, bind operations
for retrieval can be configured to require no authentication'
v CRL size can be reduced by having a short validity period for the
certificates, by using a coarse DN so that reorganization does not
invalidate a name, and not revoking for some reasons such as name change,
transfer, etc.)
I hope this helps.
-----Original Message-----
From: Ambarish Malpani [mailto:ambarish@valicert.com]
Sent: Monday, November 20, 2000 11:53 AM
To: 'Bland, Graham'; 'Simon Tardell'; ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Hi Graham,
Not quite true. There are a bunch of cases, where a root CA
certifies subCAs OCSP responders directly, whose status needs to
be checked by looking up the cert with the root's OCSP responder
(in practice, this second lookup gets optimized out).
Anyway, there are real life models, where a responder is trusted
because of a cert issued by a CA, but not necessarily trusted for
that CA. So it is possible to want to revoke an OCSP responder's
certificate.
Regarding CRLs - these are (as Simon said) a great way of getting
a snapshot of the statuses a CA has assigned. Also, by having CAs
produce and publish new CRLs as soon as there is a revocation event,
this becomes a great way of passing revocation data from a CA to
a responder.
CRLs are not scalable where they need to be distributed to a large number
of clients [read thousands/hundreds of thousands]. They are a perfectly
good way of distributing revocation data to a single client (the
responder), which can then take on the responsibility of:
a. Replicating to other responders
b. Providing OCSP responses to a large number of clients.
Also, there are real deployments where a person normally wants to revoke at
the CA, but desires to, as an emergency action, suspend directly at the
responder - so the responder uses both the CA's data (its CRL) and its own
local database to see what the status of a certificate is.
Hopefully, this helps explain the benefits of using CRLs and OCSP together.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Bland, Graham [mailto:Graham.Bland@open-talk.co.uk]
> Sent: Monday, November 20, 2000 8:09 AM
> To: 'Simon Tardell'; ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
>
> Simon,
>
> Sorry but there are still some practical caveats to be applied here.
>
> If the OCSP responder is independent of the CA in question
> then trust is
> entirely between the requestor and the responder, in this
> case the issuer
> has no knowledge of nor involvement in the trust and cannot
> invalidate the
> responder in any way.
Agreed.
>
> In the second case where the responder is a logical part of the CA in
> question, the OCSP response is signed with the certificate
> issuing key.
> The only way the CA can invalidate the responder is by
> revoking its own
> issuing key which effectively requires a reconfiguration of
> the requestor as
> the CA key would have to be implicitly trusted. Practically
> in this case
> the CA can simply shut down the responder. I cannot see a
> case where the CA
> would allow the use of its key and not have this level of control.
Agreed.
>
> The third case is where the responder is a CA designated
> responder with a
> specially marked certificate directly issued by the CA.
> In this case the logistics of the process do not make sense.
> Assuming the responder is being used to either:
> 1. provide a more timely response than CRLs
> 2. avoid having to manage the retrieval of CRLs
>
> In order to validate the OCSP response I must now either
> retrieve a CRL or
> Authority Information access (OCSP?) in order to validate the
> response. If
> the CRL is required then apart from a possible size reduction
> in the CRL I
> have to implement all the logic required to have verified the
> certificates
> status myself reducing the value of 2. Using a CRL here may
> not satisfy the
> timeliness required by 1. If Authority Information Access is
> specified then
> I have just entered a loop (assuming this specifies an OCSP
> responder which
> I then have to verify)
>
> So practically it is very difficult for a CA to invalidate an
> OCSP responder
> apart from by shutting it down, I would guess that
> specifically trusted
> responders or directly CA owned responders (which are
> effectively implicitly
> trusted) are the only practical methods that can be used.
> (unless anybody
> else has any other methods)
>
>
> Graham Bland
>
>
>
>
> -----Original Message-----
> From: Simon Tardell [mailto:simon.tardell@smarttrust.com]
> Sent: 20 November 2000 15:16
> To: 'Bland, Graham'; Simon Tardell; ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
>
> > Simon,
> >
> > There is no requirement
>
> Retracted. I don't know why I wrote that. It's Monday, I suppose.
>
> The point that I'd like to make though, is that there certainly is no
> trouble deriving trust in the responder from trust of the
> issuer (that is,
> the issuer can invalidate the responder if it feels like).
>
> Simon.
>
> Simon Tardell, Software Architect, SmartTrust
> voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
> simon.tardell@smarttrust.com, http://www.smarttrust.com
> ______________________________________________________________
> _________
>
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this
> e-mail is not intended to create legally binding commitments on
> behalf of any company in the British Interactive Broadcasting
> Holdings Limited group, nor do its contents reflect the corporate
> views or policies of any such company. Any unauthorised disclosure,
> use or dissemination, either whole or partial, is prohibited. If you
> are not the intended recipient of the message, please notify the
> sender immediately.
> ______________________________________________________________
> _________
>
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA29174 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 09:32:01 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 20 Nov 2000 10:32:12 -0700
Message-Id: <sa18fdac.048@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 20 Nov 2000 10:32:05 -0700
From: "Bob Jueneman" <bjueneman@novell.com>
To: <rsalz@caveosystems.com>
Cc: <ietf-pkix@imc.org>
Subject: Re: OCSP identifiers
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA29176
Has anyone looked into challenging the validity of that patent? I think a pretty good case could be made for prior art.
In a series of messages on the pem-dev list in September and October 1993 -- a full three years before Micali's patent was filed -- I discussed at considerable length some of the problems with CRLs in a commercial environment. On 9/21/93 I first discussed the possibility of a delta-CRL mechanism, and then went on to examine the possibility of a positive response system. On 9/22 I proposed requiring the CA to operate a trusted time-stamping service so that the CA could sign the message digest of a particular message in order to confirm that the certificate corresponding to the digital signature of the message in question was valid at the time of receipt.
I'm not a patent lawyer, but if I were one, I believe that I could convincingly argue that the method I proposed in 1993 provides well-known prior art that satisfies and hence invalidates Micali's claim 37. Depending on how claim 38 is interpreted, the CA-authenticated certificate is either the certificate of what we would now call the OCSP responder itself, or the certificate that the OCSP responder is validating; but in either case the possibility of including such a certificate in the response, if required for some purpose, would certainly be obvious to anyone skilled in the art.
Regards,
Bob
Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.
>>> Rich Salz <rsalz@caveosystems.com> 11/17/00 08:27PM >>>
> You can't get much simpler than a list of cert hashes and a status value...
If you want the OCSP responder to be able to work *only* off CRL's (e.g.,
Valicert -- arguably the OCSP market leader), then cert hash isn't very
useful.
> Probably the easiest option for everyone is to allow the pKCert ...
In a previous message I said that during work at a previous employer we
determined that this violates a patent by Micali. I held my nose and did some
searches this evening, and I believe I found it. Claims 37ff of US Patent
5,717,757 filed Nov 96 and issued Feb 98:
37. A method for providing authenticated information about certificates,
comprising the steps of:
(a) receiving a request for information about a certificate including
a proof that the certificate is issued;
(b) verifying that the proof is valid; and
(c) in response to the proof being valid, providing the requested
information.
38. A method according to claim 37, wherein the proof includes providing
an entire CA-authenticated certificate.
enjoy.
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26162 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 09:05:22 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA06873 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 11:42:26 -0500 (EST)
Message-Id: <200011201642.LAA06865@roadblock.missi.ncsc.mil>
Date: Mon, 20 Nov 2000 11:58:17 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: RE: OCSP identifiers
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: XC3kZVIx7mND1Nw41+i9Ow==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
> From: Simon Tardell <simon.tardell@smarttrust.com>
> To: "'Michael Myers'" <MMyers@verisign.com>, Margus Freudenthal
<margus@cyber.ee>, ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
> Date: Mon, 20 Nov 2000 13:45:07 +0100
>
> > Margus,
> >
> > We agree, especially regarding the observation that OCSP
> > isn't and should't be tied to CRLs.
> >
> > I don't see any problem against including cert hash among
> > OCSP's certificate identification options. Unless somebody
> > raises a significant objection, I'll put it in.
>
> Mike,
>
> I object. In principle issuerAndSerial should be enough.
Mike,
I agree with Simon. The problem I need to solve is making revocation
status information on 3-6 million subscribers available to perhaps
1 million globally-distributed relying parties with less than 6 hour
latency using the minimum possible network bandwidth.
My strawman solution is to use online status servers situated on
LANs (run by local administrators) and fed by delta CRLs. If you can
propose a non-CRL-driven solution to my problem that uses less Internet
(WAN) bandwidth, please do so. Otherwise, CRL-driven responders are a
requirement in my environment, and OCSP products which cannot be fed
by CRLs will not be purchased.
Dave
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25664 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 09:03:11 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <W5KZLGL0>; Mon, 20 Nov 2000 12:04:23 -0500
Message-ID: <8D7EC1912E25D411A32100D0B76953973E510C@scygmxs01.cygnacom.com>
From: Santosh Chokhani <chokhani@cygnacom.com>
To: Ambarish Malpani <ambarish@valicert.com>, "'Bland, Graham'" <Graham.Bland@open-talk.co.uk>, "'Simon Tardell'" <simon.tardell@smarttrust.com>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Mon, 20 Nov 2000 11:57:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05313.06CFF570"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C05313.06CFF570
Content-Type: text/plain;
charset="iso-8859-1"
Ambarish:
I do not mean to get in the middle of the debate. The issues in
architecting a solution for revocation information notification to relying
party are very complex and require consideration of topics such as:
v The communication model, i.e., which class of users are communicating with
which class of users. For example, if a user communicates with several
users who are subscriber to the same CA, a single CRL from the CA will
provide lot of relevant information and the user. On the other hand, if a
user is communicating with several users, all belonging to different CA,
each CRL is offering only information relevant to one user.
v The directory architecture in terms of where they are located and what
portions of the directory information is replicated and/or shadowed.
v The communication band-width available.
v The bind time to access the repository
v Size of the revocation response from the repository, e.g. CRL size
v Processing load on the repository, specially for digital signature
generation on the revocation information
v Processing load on the user workstation, specially for digital signature
verification on the revocation information
OCSP suffers from the following drawbacks:
v Since the revocation information is produced at the server, the
communication channel between the relying party and the server must be
secured, most likely by using digital signatures
v Signed operations will limit server scaleability since digital signature
generation is computationally intensive
v Since the revocation information is produced at the server, the scheme
requires a trusted server as opposed to an untrusted repository
v Revocation of server public key requires a method for checking server
public key status. This method is likely to be using the server public key
as an additional trust anchor or relying on a CRL mechanism.
v There needs to be non-suppressable mechanism for the CA to provide
revocation information to the trusted server
v There are no standards in the area of CA to provide non-suppressable
mechanism(s) for the revocation information to the trusted server
>From my experience, the most scaleable and versatile revocation notification
means can be achieved by using a combination of the following:
v Use of CRL
v Replication of CA directory entry for fast access to CRL
v Use of ARL
v Consolidation of ARL for all CAs in a domain through the use of
Distribution Points
v Consolidation of all the reason codes of key compromise for all
certificates in domain through the use of Distribution Point extension.
This CRL can be issued very frequently to meet the freshness requirements of
the domain. This mechanism makes the CRL mechanism as current as the OCSP
v Partitioning routine revocation information using Distribution Point CRL
if CRLs become too large
There are several other factors that can help improve the CRL retrieval
efficiency. These include:
v Repositories require the encoded CRL to send to the relying parties. The
repositories also require decoded CRL to perform searches. It may desirable
for the repository to store both encoded and decoded form as opposed to
performing encoding or decoding for each request
v Bind operation to repository can be slow if authentication is required.
If the repository does not store any private information, bind operations
for retrieval can be configured to require no authentication'
v CRL size can be reduced by having a short validity period for the
certificates, by using a coarse DN so that reorganization does not
invalidate a name, and not revoking for some reasons such as name change,
transfer, etc.)
I hope this helps.
-----Original Message-----
From: Ambarish Malpani [mailto:ambarish@valicert.com]
Sent: Monday, November 20, 2000 11:53 AM
To: 'Bland, Graham'; 'Simon Tardell'; ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Hi Graham,
Not quite true. There are a bunch of cases, where a root CA
certifies subCAs OCSP responders directly, whose status needs to
be checked by looking up the cert with the root's OCSP responder
(in practice, this second lookup gets optimized out).
Anyway, there are real life models, where a responder is trusted
because of a cert issued by a CA, but not necessarily trusted for
that CA. So it is possible to want to revoke an OCSP responder's
certificate.
Regarding CRLs - these are (as Simon said) a great way of getting
a snapshot of the statuses a CA has assigned. Also, by having CAs
produce and publish new CRLs as soon as there is a revocation event,
this becomes a great way of passing revocation data from a CA to
a responder.
CRLs are not scalable where they need to be distributed to a large number
of clients [read thousands/hundreds of thousands]. They are a perfectly
good way of distributing revocation data to a single client (the
responder), which can then take on the responsibility of:
a. Replicating to other responders
b. Providing OCSP responses to a large number of clients.
Also, there are real deployments where a person normally wants to revoke at
the CA, but desires to, as an emergency action, suspend directly at the
responder - so the responder uses both the CA's data (its CRL) and its own
local database to see what the status of a certificate is.
Hopefully, this helps explain the benefits of using CRLs and OCSP together.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Bland, Graham [mailto:Graham.Bland@open-talk.co.uk]
> Sent: Monday, November 20, 2000 8:09 AM
> To: 'Simon Tardell'; ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
>
> Simon,
>
> Sorry but there are still some practical caveats to be applied here.
>
> If the OCSP responder is independent of the CA in question
> then trust is
> entirely between the requestor and the responder, in this
> case the issuer
> has no knowledge of nor involvement in the trust and cannot
> invalidate the
> responder in any way.
Agreed.
>
> In the second case where the responder is a logical part of the CA in
> question, the OCSP response is signed with the certificate
> issuing key.
> The only way the CA can invalidate the responder is by
> revoking its own
> issuing key which effectively requires a reconfiguration of
> the requestor as
> the CA key would have to be implicitly trusted. Practically
> in this case
> the CA can simply shut down the responder. I cannot see a
> case where the CA
> would allow the use of its key and not have this level of control.
Agreed.
>
> The third case is where the responder is a CA designated
> responder with a
> specially marked certificate directly issued by the CA.
> In this case the logistics of the process do not make sense.
> Assuming the responder is being used to either:
> 1. provide a more timely response than CRLs
> 2. avoid having to manage the retrieval of CRLs
>
> In order to validate the OCSP response I must now either
> retrieve a CRL or
> Authority Information access (OCSP?) in order to validate the
> response. If
> the CRL is required then apart from a possible size reduction
> in the CRL I
> have to implement all the logic required to have verified the
> certificates
> status myself reducing the value of 2. Using a CRL here may
> not satisfy the
> timeliness required by 1. If Authority Information Access is
> specified then
> I have just entered a loop (assuming this specifies an OCSP
> responder which
> I then have to verify)
>
> So practically it is very difficult for a CA to invalidate an
> OCSP responder
> apart from by shutting it down, I would guess that
> specifically trusted
> responders or directly CA owned responders (which are
> effectively implicitly
> trusted) are the only practical methods that can be used.
> (unless anybody
> else has any other methods)
>
>
> Graham Bland
>
>
>
>
> -----Original Message-----
> From: Simon Tardell [mailto:simon.tardell@smarttrust.com]
> Sent: 20 November 2000 15:16
> To: 'Bland, Graham'; Simon Tardell; ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
>
> > Simon,
> >
> > There is no requirement
>
> Retracted. I don't know why I wrote that. It's Monday, I suppose.
>
> The point that I'd like to make though, is that there certainly is no
> trouble deriving trust in the responder from trust of the
> issuer (that is,
> the issuer can invalidate the responder if it feels like).
>
> Simon.
>
> Simon Tardell, Software Architect, SmartTrust
> voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
> simon.tardell@smarttrust.com, http://www.smarttrust.com
> ______________________________________________________________
> _________
>
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this
> e-mail is not intended to create legally binding commitments on
> behalf of any company in the British Interactive Broadcasting
> Holdings Limited group, nor do its contents reflect the corporate
> views or policies of any such company. Any unauthorised disclosure,
> use or dissemination, either whole or partial, is prohibited. If you
> are not the intended recipient of the message, please notify the
> sender immediately.
> ______________________________________________________________
> _________
>
------_=_NextPart_001_01C05313.06CFF570
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: OCSP identifiers</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Ambarish:</FONT>
</P>
<P><FONT SIZE=3D2>I do not mean to get in the middle of the =
debate. The issues in architecting a solution for revocation =
information notification to relying party are very complex and require =
consideration of topics such as:</FONT></P>
<P><FONT SIZE=3D2>v The communication model, i.e., which class of users =
are communicating with which class of users. For example, if a =
user communicates with several users who are subscriber to the same CA, =
a single CRL from the CA will provide lot of relevant information and =
the user. On the other hand, if a user is communicating with =
several users, all belonging to different CA, each CRL is offering only =
information relevant to one user.</FONT></P>
<P><FONT SIZE=3D2>v The directory architecture in terms of where they =
are located and what portions of the directory information is =
replicated and/or shadowed.</FONT></P>
<P><FONT SIZE=3D2>v The communication band-width available.</FONT>
<BR><FONT SIZE=3D2>v The bind time to access the repository</FONT>
<BR><FONT SIZE=3D2>v Size of the revocation response from the =
repository, e.g. CRL size</FONT>
<BR><FONT SIZE=3D2>v Processing load on the repository, specially for =
digital signature generation on the revocation information</FONT>
<BR><FONT SIZE=3D2>v Processing load on the user workstation, specially =
for digital signature verification on the revocation information</FONT>
</P>
<P><FONT SIZE=3D2>OCSP suffers from the following drawbacks:</FONT>
</P>
<P><FONT SIZE=3D2>v Since the revocation information is produced at the =
server, the communication channel between the relying party and the =
server must be secured, most likely by using digital =
signatures</FONT></P>
<P><FONT SIZE=3D2>v Signed operations will limit server scaleability =
since digital signature generation is computationally intensive</FONT>
<BR><FONT SIZE=3D2>v Since the revocation information is produced at =
the server, the scheme requires a trusted server as opposed to an =
untrusted repository</FONT></P>
<P><FONT SIZE=3D2>v Revocation of server public key requires a method =
for checking server public key status. This method is likely to =
be using the server public key as an additional trust anchor or relying =
on a CRL mechanism.</FONT></P>
<P><FONT SIZE=3D2>v There needs to be non-suppressable mechanism =
for the CA to provide revocation information to the trusted server =
</FONT>
<BR><FONT SIZE=3D2>v There are no standards in the area of CA to =
provide non-suppressable mechanism(s) for the revocation information to =
the trusted server</FONT></P>
<P><FONT SIZE=3D2>From my experience, the most scaleable and versatile =
revocation notification means can be achieved by using a combination of =
the following:</FONT></P>
<P><FONT SIZE=3D2>v Use of CRL</FONT>
<BR><FONT SIZE=3D2>v Replication of CA directory entry for fast access =
to CRL</FONT>
<BR><FONT SIZE=3D2>v Use of ARL</FONT>
<BR><FONT SIZE=3D2>v Consolidation of ARL for all CAs in a domain =
through the use of Distribution Points </FONT>
<BR><FONT SIZE=3D2>v Consolidation of all the reason codes of key =
compromise for all certificates in domain through the use of =
Distribution Point extension. This CRL can be issued very =
frequently to meet the freshness requirements of the domain. This =
mechanism makes the CRL mechanism as current as the OCSP</FONT></P>
<P><FONT SIZE=3D2>v Partitioning routine revocation information using =
Distribution Point CRL if CRLs become too large</FONT>
</P>
<P><FONT SIZE=3D2>There are several other factors that can help improve =
the CRL retrieval efficiency. These include:</FONT>
</P>
<P><FONT SIZE=3D2>v Repositories require the encoded CRL to send to the =
relying parties. The repositories also require decoded CRL to =
perform searches. It may desirable for the repository to store =
both encoded and decoded form as opposed to performing encoding or =
decoding for each request</FONT></P>
<P><FONT SIZE=3D2>v Bind operation to repository can be slow if =
authentication is required. If the repository does not store any =
private information, bind operations for retrieval can be configured to =
require no authentication'</FONT></P>
<P><FONT SIZE=3D2>v CRL size can be reduced by having a short validity =
period for the certificates, by using a coarse DN so that =
reorganization does not invalidate a name, and not revoking for some =
reasons such as name change, transfer, etc.)</FONT></P>
<P><FONT SIZE=3D2>I hope this helps.</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ambarish Malpani [<A =
HREF=3D"mailto:ambarish@valicert.com">mailto:ambarish@valicert.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, November 20, 2000 11:53 AM</FONT>
<BR><FONT SIZE=3D2>To: 'Bland, Graham'; 'Simon Tardell'; =
ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP identifiers</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>Hi Graham,</FONT>
<BR><FONT SIZE=3D2> Not quite true. There are a bunch =
of cases, where a root CA</FONT>
<BR><FONT SIZE=3D2>certifies subCAs OCSP responders directly, whose =
status needs to</FONT>
<BR><FONT SIZE=3D2>be checked by looking up the cert with the root's =
OCSP responder</FONT>
<BR><FONT SIZE=3D2>(in practice, this second lookup gets optimized =
out).</FONT>
</P>
<P><FONT SIZE=3D2>Anyway, there are real life models, where a responder =
is trusted</FONT>
<BR><FONT SIZE=3D2>because of a cert issued by a CA, but not =
necessarily trusted for</FONT>
<BR><FONT SIZE=3D2>that CA. So it is possible to want to revoke an OCSP =
responder's</FONT>
<BR><FONT SIZE=3D2>certificate.</FONT>
</P>
<P><FONT SIZE=3D2>Regarding CRLs - these are (as Simon said) a great =
way of getting</FONT>
<BR><FONT SIZE=3D2>a snapshot of the statuses a CA has assigned. Also, =
by having CAs</FONT>
<BR><FONT SIZE=3D2>produce and publish new CRLs as soon as there is a =
revocation event,</FONT>
<BR><FONT SIZE=3D2>this becomes a great way of passing revocation data =
from a CA to</FONT>
<BR><FONT SIZE=3D2>a responder.</FONT>
</P>
<P><FONT SIZE=3D2>CRLs are not scalable where they need to be =
distributed to a large number</FONT>
<BR><FONT SIZE=3D2>of clients [read thousands/hundreds of thousands]. =
They are a perfectly</FONT>
<BR><FONT SIZE=3D2>good way of distributing revocation data to a single =
client (the</FONT>
<BR><FONT SIZE=3D2>responder), which can then take on the =
responsibility of:</FONT>
<BR><FONT SIZE=3D2>a. Replicating to other responders</FONT>
<BR><FONT SIZE=3D2>b. Providing OCSP responses to a large number of =
clients.</FONT>
</P>
<P><FONT SIZE=3D2>Also, there are real deployments where a person =
normally wants to revoke at</FONT>
<BR><FONT SIZE=3D2>the CA, but desires to, as an emergency action, =
suspend directly at the</FONT>
<BR><FONT SIZE=3D2>responder - so the responder uses both the CA's data =
(its CRL) and its own</FONT>
<BR><FONT SIZE=3D2>local database to see what the status of a =
certificate is.</FONT>
</P>
<P><FONT SIZE=3D2>Hopefully, this helps explain the benefits of using =
CRLs and OCSP together.</FONT>
</P>
<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Ambarish</FONT>
</P>
<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
------</FONT>
<BR><FONT SIZE=3D2>Ambarish Malpani</FONT>
<BR><FONT =
SIZE=3D2>Architect =
=
=
=
650.567.5457</FONT>
<BR><FONT SIZE=3D2>ValiCert, Inc. &nb=
sp; &nb=
sp; &nb=
sp; ambarish@valicert.com</FONT>
<BR><FONT SIZE=3D2>339 N. Bernardo =
Ave. &n=
bsp; &n=
bsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>Mountain View, CA 94043</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Bland, Graham [<A =
HREF=3D"mailto:Graham.Bland@open-talk.co.uk">mailto:Graham.Bland@open-ta=
lk.co.uk</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Monday, November 20, 2000 8:09 AM</FONT>
<BR><FONT SIZE=3D2>> To: 'Simon Tardell'; ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: OCSP identifiers</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Simon,</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Sorry but there are still some practical =
caveats to be applied here.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> If the OCSP responder is independent of the CA =
in question </FONT>
<BR><FONT SIZE=3D2>> then trust is</FONT>
<BR><FONT SIZE=3D2>> entirely between the requestor and the =
responder, in this </FONT>
<BR><FONT SIZE=3D2>> case the issuer</FONT>
<BR><FONT SIZE=3D2>> has no knowledge of nor involvement in the =
trust and cannot </FONT>
<BR><FONT SIZE=3D2>> invalidate the</FONT>
<BR><FONT SIZE=3D2>> responder in any way.</FONT>
</P>
<P><FONT SIZE=3D2>Agreed.</FONT>
</P>
<P><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> In the second case where the responder is a =
logical part of the CA in</FONT>
<BR><FONT SIZE=3D2>> question, the OCSP response is signed with the =
certificate </FONT>
<BR><FONT SIZE=3D2>> issuing key.</FONT>
<BR><FONT SIZE=3D2>> The only way the CA can invalidate the =
responder is by </FONT>
<BR><FONT SIZE=3D2>> revoking its own</FONT>
<BR><FONT SIZE=3D2>> issuing key which effectively requires a =
reconfiguration of </FONT>
<BR><FONT SIZE=3D2>> the requestor as</FONT>
<BR><FONT SIZE=3D2>> the CA key would have to be implicitly =
trusted. Practically </FONT>
<BR><FONT SIZE=3D2>> in this case</FONT>
<BR><FONT SIZE=3D2>> the CA can simply shut down the =
responder. I cannot see a </FONT>
<BR><FONT SIZE=3D2>> case where the CA</FONT>
<BR><FONT SIZE=3D2>> would allow the use of its key and not have =
this level of control.</FONT>
</P>
<P><FONT SIZE=3D2>Agreed.</FONT>
</P>
<P><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The third case is where the responder is a CA =
designated </FONT>
<BR><FONT SIZE=3D2>> responder with a</FONT>
<BR><FONT SIZE=3D2>> specially marked certificate directly issued by =
the CA.</FONT>
<BR><FONT SIZE=3D2>> In this case the logistics of the process do =
not make sense.</FONT>
<BR><FONT SIZE=3D2>> Assuming the responder is being used to =
either: </FONT>
<BR><FONT SIZE=3D2>> 1. provide a more timely response than CRLs =
</FONT>
<BR><FONT SIZE=3D2>> 2. avoid having to manage the retrieval of =
CRLs</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> In order to validate the OCSP response I must =
now either </FONT>
<BR><FONT SIZE=3D2>> retrieve a CRL or</FONT>
<BR><FONT SIZE=3D2>> Authority Information access (OCSP?) in order =
to validate the </FONT>
<BR><FONT SIZE=3D2>> response. If</FONT>
<BR><FONT SIZE=3D2>> the CRL is required then apart from a possible =
size reduction </FONT>
<BR><FONT SIZE=3D2>> in the CRL I</FONT>
<BR><FONT SIZE=3D2>> have to implement all the logic required to =
have verified the </FONT>
<BR><FONT SIZE=3D2>> certificates</FONT>
<BR><FONT SIZE=3D2>> status myself reducing the value of 2. Using a =
CRL here may </FONT>
<BR><FONT SIZE=3D2>> not satisfy the</FONT>
<BR><FONT SIZE=3D2>> timeliness required by 1. If Authority =
Information Access is </FONT>
<BR><FONT SIZE=3D2>> specified then</FONT>
<BR><FONT SIZE=3D2>> I have just entered a loop (assuming this =
specifies an OCSP </FONT>
<BR><FONT SIZE=3D2>> responder which</FONT>
<BR><FONT SIZE=3D2>> I then have to verify) </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> So practically it is very difficult for a CA to =
invalidate an </FONT>
<BR><FONT SIZE=3D2>> OCSP responder</FONT>
<BR><FONT SIZE=3D2>> apart from by shutting it down, I would guess =
that </FONT>
<BR><FONT SIZE=3D2>> specifically trusted</FONT>
<BR><FONT SIZE=3D2>> responders or directly CA owned responders =
(which are </FONT>
<BR><FONT SIZE=3D2>> effectively implicitly</FONT>
<BR><FONT SIZE=3D2>> trusted) are the only practical methods that =
can be used. </FONT>
<BR><FONT SIZE=3D2>> (unless anybody</FONT>
<BR><FONT SIZE=3D2>> else has any other methods)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Graham Bland</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Simon Tardell [<A =
HREF=3D"mailto:simon.tardell@smarttrust.com">mailto:simon.tardell@smartt=
rust.com</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: 20 November 2000 15:16</FONT>
<BR><FONT SIZE=3D2>> To: 'Bland, Graham'; Simon Tardell; =
ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: OCSP identifiers</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > Simon,</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > There is no requirement </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Retracted. I don't know why I wrote that. It's =
Monday, I suppose.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The point that I'd like to make though, is that =
there certainly is no</FONT>
<BR><FONT SIZE=3D2>> trouble deriving trust in the responder from =
trust of the </FONT>
<BR><FONT SIZE=3D2>> issuer (that is,</FONT>
<BR><FONT SIZE=3D2>> the issuer can invalidate the responder if it =
feels like).</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Simon.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Simon Tardell, Software Architect, =
SmartTrust</FONT>
<BR><FONT SIZE=3D2>> voice +46 8 7755225, fax +46 8 7267912, cell =
+46 70 3198319</FONT>
<BR><FONT SIZE=3D2>> simon.tardell@smarttrust.com, <A =
HREF=3D"http://www.smarttrust.com" =
TARGET=3D"_blank">http://www.smarttrust.com</A></FONT>
<BR><FONT SIZE=3D2>> =
______________________________________________________________</FONT>
<BR><FONT SIZE=3D2>> _________</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> This message is confidential and is intended =
for the addressee only;</FONT>
<BR><FONT SIZE=3D2>> unless clearly stated that this disclaimer =
should not apply, this </FONT>
<BR><FONT SIZE=3D2>> e-mail is not intended to create legally =
binding commitments on </FONT>
<BR><FONT SIZE=3D2>> behalf of any company in the British =
Interactive Broadcasting </FONT>
<BR><FONT SIZE=3D2>> Holdings Limited group, nor do its =
contents reflect the corporate </FONT>
<BR><FONT SIZE=3D2>> views or policies of any such company. Any =
unauthorised disclosure, </FONT>
<BR><FONT SIZE=3D2>> use or dissemination, either whole or partial, =
is prohibited. If you </FONT>
<BR><FONT SIZE=3D2>> are not the intended recipient of the message, =
please notify the</FONT>
<BR><FONT SIZE=3D2>> sender immediately.</FONT>
<BR><FONT SIZE=3D2>> =
______________________________________________________________</FONT>
<BR><FONT SIZE=3D2>> _________</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C05313.06CFF570--
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25276 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 08:55:09 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4C008011OQAK@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 20 Nov 2000 08:55:38 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4C0087V1OQ07@ext-mail.valicert.com>; Mon, 20 Nov 2000 08:55:38 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <XDY1Z49K>; Mon, 20 Nov 2000 08:53:25 -0800
Content-return: allowed
Date: Mon, 20 Nov 2000 08:53:24 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: OCSP identifiers
To: "'Bland, Graham'" <Graham.Bland@open-talk.co.uk>, "'Simon Tardell'" <simon.tardell@smarttrust.com>, ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E153047@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Hi Graham,
Not quite true. There are a bunch of cases, where a root CA
certifies subCAs OCSP responders directly, whose status needs to
be checked by looking up the cert with the root's OCSP responder
(in practice, this second lookup gets optimized out).
Anyway, there are real life models, where a responder is trusted
because of a cert issued by a CA, but not necessarily trusted for
that CA. So it is possible to want to revoke an OCSP responder's
certificate.
Regarding CRLs - these are (as Simon said) a great way of getting
a snapshot of the statuses a CA has assigned. Also, by having CAs
produce and publish new CRLs as soon as there is a revocation event,
this becomes a great way of passing revocation data from a CA to
a responder.
CRLs are not scalable where they need to be distributed to a large number
of clients [read thousands/hundreds of thousands]. They are a perfectly
good way of distributing revocation data to a single client (the
responder), which can then take on the responsibility of:
a. Replicating to other responders
b. Providing OCSP responses to a large number of clients.
Also, there are real deployments where a person normally wants to revoke at
the CA, but desires to, as an emergency action, suspend directly at the
responder - so the responder uses both the CA's data (its CRL) and its own
local database to see what the status of a certificate is.
Hopefully, this helps explain the benefits of using CRLs and OCSP together.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Bland, Graham [mailto:Graham.Bland@open-talk.co.uk]
> Sent: Monday, November 20, 2000 8:09 AM
> To: 'Simon Tardell'; ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
>
> Simon,
>
> Sorry but there are still some practical caveats to be applied here.
>
> If the OCSP responder is independent of the CA in question
> then trust is
> entirely between the requestor and the responder, in this
> case the issuer
> has no knowledge of nor involvement in the trust and cannot
> invalidate the
> responder in any way.
Agreed.
>
> In the second case where the responder is a logical part of the CA in
> question, the OCSP response is signed with the certificate
> issuing key.
> The only way the CA can invalidate the responder is by
> revoking its own
> issuing key which effectively requires a reconfiguration of
> the requestor as
> the CA key would have to be implicitly trusted. Practically
> in this case
> the CA can simply shut down the responder. I cannot see a
> case where the CA
> would allow the use of its key and not have this level of control.
Agreed.
>
> The third case is where the responder is a CA designated
> responder with a
> specially marked certificate directly issued by the CA.
> In this case the logistics of the process do not make sense.
> Assuming the responder is being used to either:
> 1. provide a more timely response than CRLs
> 2. avoid having to manage the retrieval of CRLs
>
> In order to validate the OCSP response I must now either
> retrieve a CRL or
> Authority Information access (OCSP?) in order to validate the
> response. If
> the CRL is required then apart from a possible size reduction
> in the CRL I
> have to implement all the logic required to have verified the
> certificates
> status myself reducing the value of 2. Using a CRL here may
> not satisfy the
> timeliness required by 1. If Authority Information Access is
> specified then
> I have just entered a loop (assuming this specifies an OCSP
> responder which
> I then have to verify)
>
> So practically it is very difficult for a CA to invalidate an
> OCSP responder
> apart from by shutting it down, I would guess that
> specifically trusted
> responders or directly CA owned responders (which are
> effectively implicitly
> trusted) are the only practical methods that can be used.
> (unless anybody
> else has any other methods)
>
>
> Graham Bland
>
>
>
>
> -----Original Message-----
> From: Simon Tardell [mailto:simon.tardell@smarttrust.com]
> Sent: 20 November 2000 15:16
> To: 'Bland, Graham'; Simon Tardell; ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
>
> > Simon,
> >
> > There is no requirement
>
> Retracted. I don't know why I wrote that. It's Monday, I suppose.
>
> The point that I'd like to make though, is that there certainly is no
> trouble deriving trust in the responder from trust of the
> issuer (that is,
> the issuer can invalidate the responder if it feels like).
>
> Simon.
>
> Simon Tardell, Software Architect, SmartTrust
> voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
> simon.tardell@smarttrust.com, http://www.smarttrust.com
> ______________________________________________________________
> _________
>
> This message is confidential and is intended for the addressee only;
> unless clearly stated that this disclaimer should not apply, this
> e-mail is not intended to create legally binding commitments on
> behalf of any company in the British Interactive Broadcasting
> Holdings Limited group, nor do its contents reflect the corporate
> views or policies of any such company. Any unauthorised disclosure,
> use or dissemination, either whole or partial, is prohibited. If you
> are not the intended recipient of the message, please notify the
> sender immediately.
> ______________________________________________________________
> _________
>
Received: from internet.across ([213.212.5.232]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA25045 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 08:53:26 -0800 (PST)
Received: FROM acrossw01.across BY internet.across ; Mon Nov 20 17:55:47 2000 +0100
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <XAVQ830K>; Mon, 20 Nov 2000 17:52:10 +0100
Message-ID: <E5C2786F90B4D4119A200008C716F45D269F64@acrossw01.acrosswireless.com>
From: Simon Tardell <simon.tardell@smarttrust.com>
To: "'Bland, Graham'" <Graham.Bland@open-talk.co.uk>, Simon Tardell <simon.tardell@smarttrust.com>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Mon, 20 Nov 2000 17:52:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
> Simon,
>
> Sorry but there are still some practical caveats to be applied here.
>
[...]
> In the second case where the responder is a logical part of the CA in
> question, the OCSP response is signed with the certificate issuing key.
> The only way the CA can invalidate the responder is by revoking its own
> issuing key which effectively requires a reconfiguration of
> the requestor as the CA key would have to be implicitly trusted.
Practically
> in this case the CA can simply shut down the responder. I cannot see a
> case where the CA would allow the use of its key and not have this level
of control.
This obviously works, but there are a number of issues concerning
availability and scalability that would be more difficult to address in this
scenario, so I don't see it as a high-end scenario.
> The third case is where the responder is a CA designated
> responder with a
> specially marked certificate directly issued by the CA.
> In this case the logistics of the process do not make sense.
> Assuming the responder is being used to either:
> 1. provide a more timely response than CRLs
> 2. avoid having to manage the retrieval of CRLs
>
> In order to validate the OCSP response I must now either retrieve a CRL or
> Authority Information access (OCSP?) in order to validate the response.
If
> the CRL is required then apart from a possible size reduction in the CRL I
> have to implement all the logic required to have verified the
> certificates status myself reducing the value of 2. Using a CRL here may
> not satisfy the timeliness required by 1. If Authority Information Access
is
> specified then I have just entered a loop (assuming this specifies an OCSP
> responder which I then have to verify)
>
> So practically it is very difficult for a CA to invalidate an
> OCSP responder apart from by shutting it down, I would guess that
> specifically trusted responders or directly CA owned responders (which are
> effectively implicitly trusted) are the only practical methods that can be
used.
> (unless anybody else has any other methods)
"Timeliness" is of course relative to the risk you want to expose yourself
to. But there definitely is a practical method that does not involve CRLs or
OCSP "chains". If the CA that designates the responder gives the responder a
short-lived certificate, and renews that certificate periodically (within
the lifespan), revocation becomes tantamount to stopping reissuance. The
shorter the lifespan, the less the window for a perpetrator. And how short
can the window be anyway, for other reasons? I mean, there are people
involved.
But going back to the original question: Who is it that should be doing the
revoking here? Is it the responder that should be revoking the CA (the
certHash model), or is it the CA that should be revoking the responder?
Simon.
Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
simon.tardell@smarttrust.com, http://www.smarttrust.com
Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA22451 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 08:09:17 -0800 (PST)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Mon, 20 Nov 2000 16:08:51 -0000 (GMT Standard Time)
Received: by claudio with Internet Mail Service (5.5.2650.21) id <W2M4AMZH>; Mon, 20 Nov 2000 16:08:51 -0000
Message-ID: <36086CC80304D3119B040008C75DF596049433A8@claudio>
From: "Bland, Graham" <Graham.Bland@open-talk.co.uk>
To: "'Simon Tardell'" <simon.tardell@smarttrust.com>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Mon, 20 Nov 2000 16:08:48 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Simon,
Sorry but there are still some practical caveats to be applied here.
If the OCSP responder is independent of the CA in question then trust is
entirely between the requestor and the responder, in this case the issuer
has no knowledge of nor involvement in the trust and cannot invalidate the
responder in any way.
In the second case where the responder is a logical part of the CA in
question, the OCSP response is signed with the certificate issuing key.
The only way the CA can invalidate the responder is by revoking its own
issuing key which effectively requires a reconfiguration of the requestor as
the CA key would have to be implicitly trusted. Practically in this case
the CA can simply shut down the responder. I cannot see a case where the CA
would allow the use of its key and not have this level of control.
The third case is where the responder is a CA designated responder with a
specially marked certificate directly issued by the CA.
In this case the logistics of the process do not make sense.
Assuming the responder is being used to either:
1. provide a more timely response than CRLs
2. avoid having to manage the retrieval of CRLs
In order to validate the OCSP response I must now either retrieve a CRL or
Authority Information access (OCSP?) in order to validate the response. If
the CRL is required then apart from a possible size reduction in the CRL I
have to implement all the logic required to have verified the certificates
status myself reducing the value of 2. Using a CRL here may not satisfy the
timeliness required by 1. If Authority Information Access is specified then
I have just entered a loop (assuming this specifies an OCSP responder which
I then have to verify)
So practically it is very difficult for a CA to invalidate an OCSP responder
apart from by shutting it down, I would guess that specifically trusted
responders or directly CA owned responders (which are effectively implicitly
trusted) are the only practical methods that can be used. (unless anybody
else has any other methods)
Graham Bland
-----Original Message-----
From: Simon Tardell [mailto:simon.tardell@smarttrust.com]
Sent: 20 November 2000 15:16
To: 'Bland, Graham'; Simon Tardell; ietf-pkix@imc.org
Subject: RE: OCSP identifiers
> Simon,
>
> There is no requirement
Retracted. I don't know why I wrote that. It's Monday, I suppose.
The point that I'd like to make though, is that there certainly is no
trouble deriving trust in the responder from trust of the issuer (that is,
the issuer can invalidate the responder if it feels like).
Simon.
Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
simon.tardell@smarttrust.com, http://www.smarttrust.com
_______________________________________________________________________
This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this
e-mail is not intended to create legally binding commitments on
behalf of any company in the British Interactive Broadcasting
Holdings Limited group, nor do its contents reflect the corporate
views or policies of any such company. Any unauthorised disclosure,
use or dissemination, either whole or partial, is prohibited. If you
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________
Received: from internet.across ([213.212.5.232]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA12634 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 07:17:35 -0800 (PST)
Received: FROM acrossw01.across BY internet.across ; Mon Nov 20 16:19:54 2000 +0100
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <XAVQ834K>; Mon, 20 Nov 2000 16:16:18 +0100
Message-ID: <E5C2786F90B4D4119A200008C716F45D269F62@acrossw01.acrosswireless.com>
From: Simon Tardell <simon.tardell@smarttrust.com>
To: "'Bland, Graham'" <Graham.Bland@open-talk.co.uk>, Simon Tardell <simon.tardell@smarttrust.com>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Mon, 20 Nov 2000 16:16:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
> Simon,
>
> There is no requirement
Retracted. I don't know why I wrote that. It's Monday, I suppose.
The point that I'd like to make though, is that there certainly is no
trouble deriving trust in the responder from trust of the issuer (that is,
the issuer can invalidate the responder if it feels like).
Simon.
Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
simon.tardell@smarttrust.com, http://www.smarttrust.com
Received: from claudio.bib.co.uk (gateway.bib.co.uk [195.171.24.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA10140 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 06:59:38 -0800 (PST)
Received: from 127.0.0.1 by claudio.bib.co.uk (InterScan E-Mail VirusWall NT); Mon, 20 Nov 2000 14:59:12 -0000 (GMT Standard Time)
Received: by claudio with Internet Mail Service (5.5.2650.21) id <W2M4AMB6>; Mon, 20 Nov 2000 14:59:12 -0000
Message-ID: <36086CC80304D3119B040008C75DF596049433A6@claudio>
From: "Bland, Graham" <Graham.Bland@open-talk.co.uk>
To: "'Simon Tardell'" <simon.tardell@smarttrust.com>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Mon, 20 Nov 2000 14:59:08 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Simon,
There is no requirement that I can see for the OCSP responder to be
authorised or trusted by the issuer, I quote
All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:
-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA, indicating
that the responder may issue OCSP responses for that CA
The second case here implies trust only between the requestor and the
responder.
Also in section 4.2.2.2 local configuration of OCSP signing authority by the
requestor is allowed bypassing any CA authority or involvement.
Graham Bland
-----Original Message-----
From: Simon Tardell [mailto:simon.tardell@smarttrust.com]
Sent: 20 November 2000 14:39
To: 'Margus Freudenthal'; Simon Tardell; ietf-pkix@imc.org
Cc: 'Michael Myers'
Subject: RE: OCSP identifiers
> Hello.
Hi.
> Simon Tardell wrote:
> >
> > CertHash is proposed to solve the problem of compromise of the issuer
key.
> > It turns the question from a revocation query to an issuance query. It
also
> > turns the responder from being someone who answers on delegation into
> > someone who is an authority on its own (i.e. it can, in effect,
invalidate
> > the issuer).
>
> Well, OCSP response is currently signed by OCSP responder
> (which may or may not be the CA). If you do not trust the OCSP responder,
then even
> CRL-based OCSP service can't give you satisfactory answers
> because they do not contain CA's signature. If you want assurance given
by CA, you
> should download the CRL and ceck it (and steer clear of the OCSP
> protocol).
Not at all. My trust in the OCSP responder derives from my trust in the CA.
The OCSP responses must (and that's a MUST...) either be signed by the
issuer, or someone authorized (by the issuer) to do so. Other models can be
imagined, such as the one you advocate, but they are very different model.
I'm not against such models, but they should not break the primary mode of
the protocol.
If the issuer revokes the authorization of the responder for whatever
reason, I expect it to revoke the responder keys. That's assurance enough
for most purposes. How the client learn about this is a deployment issue.
Simon.
Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
simon.tardell@smarttrust.com, http://www.smarttrust.com
_______________________________________________________________________
This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this
e-mail is not intended to create legally binding commitments on
behalf of any company in the British Interactive Broadcasting
Holdings Limited group, nor do its contents reflect the corporate
views or policies of any such company. Any unauthorised disclosure,
use or dissemination, either whole or partial, is prohibited. If you
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________
Received: from internet.across ([213.212.5.232]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA08897 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 06:41:22 -0800 (PST)
Received: FROM acrossw01.across BY internet.across ; Mon Nov 20 15:43:03 2000 +0100
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <XAVQ831Q>; Mon, 20 Nov 2000 15:39:27 +0100
Message-ID: <E5C2786F90B4D4119A200008C716F45D269F5F@acrossw01.acrosswireless.com>
From: Simon Tardell <simon.tardell@smarttrust.com>
To: "'Margus Freudenthal'" <margus@cyber.ee>, Simon Tardell <simon.tardell@smarttrust.com>, ietf-pkix@imc.org
Cc: "'Michael Myers'" <MMyers@verisign.com>
Subject: RE: OCSP identifiers
Date: Mon, 20 Nov 2000 15:39:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
> Hello.
Hi.
> Simon Tardell wrote:
> >
> > CertHash is proposed to solve the problem of compromise of the issuer
key.
> > It turns the question from a revocation query to an issuance query. It
also
> > turns the responder from being someone who answers on delegation into
> > someone who is an authority on its own (i.e. it can, in effect,
invalidate
> > the issuer).
>
> Well, OCSP response is currently signed by OCSP responder
> (which may or may not be the CA). If you do not trust the OCSP responder,
then even
> CRL-based OCSP service can't give you satisfactory answers
> because they do not contain CA's signature. If you want assurance given
by CA, you
> should download the CRL and ceck it (and steer clear of the OCSP
> protocol).
Not at all. My trust in the OCSP responder derives from my trust in the CA.
The OCSP responses must (and that's a MUST...) either be signed by the
issuer, or someone authorized (by the issuer) to do so. Other models can be
imagined, such as the one you advocate, but they are very different model.
I'm not against such models, but they should not break the primary mode of
the protocol.
If the issuer revokes the authorization of the responder for whatever
reason, I expect it to revoke the responder keys. That's assurance enough
for most purposes. How the client learn about this is a deployment issue.
Simon.
Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
simon.tardell@smarttrust.com, http://www.smarttrust.com
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07760 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 06:20:54 -0800 (PST)
Received: from kiku.itsise (kiku.itsise [192.168.2.2]) by atsgw.cyber.ee (8.11.1/8.11.1) with ESMTP id eAKEKXi23359; Mon, 20 Nov 2000 16:20:33 +0200
Received: from cyber.ee (dino.itsise [192.168.2.137]) by kiku.itsise (8.9.1a/8.9.1) with ESMTP id QAA22609; Mon, 20 Nov 2000 16:19:45 +0200
Message-ID: <3A19339C.FD451DBE@cyber.ee>
Date: Mon, 20 Nov 2000 16:22:20 +0200
From: Margus Freudenthal <margus@cyber.ee>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: Simon Tardell <simon.tardell@smarttrust.com>, ietf-pkix@imc.org
CC: "'Michael Myers'" <MMyers@verisign.com>
Subject: Re: OCSP identifiers
References: <E5C2786F90B4D4119A200008C716F45D269F5B@acrossw01.acrosswireless.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello.
Simon Tardell wrote:
>
> CertHash is proposed to solve the problem of compromise of the issuer key.
> It turns the question from a revocation query to an issuance query. It also
> turns the responder from being someone who answers on delegation into
> someone who is an authority on its own (i.e. it can, in effect, invalidate
> the issuer).
Well, OCSP response is currently signed by OCSP responder (which may or
may not be the CA). If you do not trust the OCSP responder, then even
CRL-based OCSP service can't give you satisfactory answers because they
do not contain CA's signature. If you want assurance given by CA, you
should download the CRL and ceck it (and steer clear of the OCSP
protocol).
--
Margus Freudenthal margus@cyber.ee
Cybernetica http://www.cyber.ee/
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA05122 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 05:20:45 -0800 (PST)
Received: from plipp [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A558970102; Mon, 20 Nov 2000 14:21:28 +0100
From: "Peter Lipp" <Peter.Lipp@iaik.at>
To: "Anders Rundgren" <anders.rundgren@telia.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
Subject: AW: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
Date: Mon, 20 Nov 2000 14:21:42 +0100
Message-ID: <OEEELKIFKJHGADBKOFPNIEGJCBAA.Peter.Lipp@iaik.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <00a201c052ea$8b453f50$0201a8c0@vincent.se>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Anders,
>MY interest in this is just to get the ball rolling and maybe participate
in forming a new WG.
>It may though turn out that W3C is a better place to be in, as they
actually "host" the core of all other
>XML technologies.
As I already mentioned, a joint WG would be optimal - to bring in experts
from both sides. I'll ask in the XML-DSig-list what they think...
Peter
Received: from internet.across ([213.212.5.232]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA02810 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 04:46:29 -0800 (PST)
Received: FROM acrossw01.across BY internet.across ; Mon Nov 20 13:48:46 2000 +0100
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <XAVQ8NQM>; Mon, 20 Nov 2000 13:45:10 +0100
Message-ID: <E5C2786F90B4D4119A200008C716F45D269F5B@acrossw01.acrosswireless.com>
From: Simon Tardell <simon.tardell@smarttrust.com>
To: "'Michael Myers'" <MMyers@verisign.com>, Margus Freudenthal <margus@cyber.ee>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Mon, 20 Nov 2000 13:45:07 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
> Margus,
>
> We agree, especially regarding the observation that OCSP
> isn't and should't be tied to CRLs.
>
> I don't see any problem against including cert hash among
> OCSP's certificate identification options. Unless somebody
> raises a significant objection, I'll put it in.
Mike,
I object. In principle issuerAndSerial should be enough.
The public key hash (of CertId) was introduced to guarantee that the client
and responder agreed on what the issuer cert was, but I think this is better
done in an out-of-band manner (the responder cert, or its issuer's cert,
which may very well be the same cert, must still be installed into the
client in an out-of-band manner). The hashing of the issuer DN (by an
algorithm of the client's choice) I think was a bad move, it creates
unnecessary complexity in the responder.
CertHash is proposed to solve the problem of compromise of the issuer key.
It turns the question from a revocation query to an issuance query. It also
turns the responder from being someone who answers on delegation into
someone who is an authority on its own (i.e. it can, in effect, invalidate
the issuer). While the solution is fine as a solution to that problem (and
also is mandated in certain PKIs), it is not the only solution to that
problem, and it brings complication if you don't want to use that solution,
or don't care about that problem. Hence certHash should not be the primary
identifier of a certificate. It could be used as a single request extension,
to qualify the query, though. (Question: A query about an identifier that
the responder can't resolve, e.g. a certHash, is it 'unknown' or
'malformedRequest'?)
While CRLs are a bad way of answering revocation queries, I don't think they
are irrelevant to OCSP responders. CRLs are a way to serialize (snapshot)
the revocation status of a CA's issued certs at one point in time, and as
such useful to bootstrap the cache of an OCSP responder. This is important
if you want availability. If certHash is made a primary certificate
identifier, this doesn't work anymore. There is no corresponding format for
making a snapshot of the issuance status of CA's issued certs (a CIL?). Nor,
do I think, should there be.
Simon.
Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
simon.tardell@smarttrust.com, http://www.smarttrust.com
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27956 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 04:09:05 -0800 (PST)
Received: from mega (t6o69p97.telia.com [213.64.110.217]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id NAA14175; Mon, 20 Nov 2000 13:09:30 +0100 (CET)
Message-ID: <00a201c052ea$8b453f50$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Michael Zolotarev" <mzolotarev@baltimore.com>, "Stephen Kent" <kent@bbn.com>, "Nada Kapidzic Cicovic" <nada@entegrity.com>, <jis@mit.edu>, <mleech@nortelnetworks.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCAD8B319@sydneymail1.jp.zergo.com.au> <5.0.1.4.0.20001120103927.02ef7a10@exchsvr1.entegrity.com>
Subject: Scope of PKIXML-WG. Was: Should PKIX protocols support XML well?
Date: Mon, 20 Nov 2000 13:08:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA27957
Nada,
> Even if you decide to go with a separate WG it should not be called PKIXML,
> since, in my opinion, it should not cover the whole work of PKIX, but only
> a small subset. The name PKIXML implies replacing ASN.1 with XML for
> everything, and that would be wrong and probably not very productive.
PKIXML should be translated as "PKI with XML-flavor" which can be as narrow
or wide as the _MEMBERS_ want it to be. If there is considerable
support for XML PKCs - let there be one. I don't think that there should be any kind of restriction
on the scope (except PKI and XML), and regarding PKIXML's relation to ASN.1 it is so far
not specified at all.
MY interest in this is just to get the ball rolling and maybe participate in forming a new WG.
It may though turn out that W3C is a better place to be in, as they actually "host" the core of all other
XML technologies.
> >I.e. the ONLY question left is (still) the subject of this message:
> >
> >========================================================
> >Should PKIX support XML, or is the proper way to go ahead with PKIXML WG?
> >========================================================
>
> Have you not agreed with my last mail that PKCs should stay defined in
> ASN.1/DER as they are?
Yes. But PKCs are already defined and need AFAIK no further work.
> Most of the discussions so far on the list was regarding ACs and possibly
> some kind of remote certificate path building and verification protocols
> being encoded in XML, so that non-ASN.1 aware clients can still use
> existing PKI infrastructures. This is _not_ the whole PKIX, but a small
> subset of it. That is exactly what Michael referred to as apples vs. oranges.
Ok, I did not interprete Michael in that way. If all new exciting stuff including ACs effectively become
represented in XML the scope grows from "a small subset" to "mainstream".
Lets say that PKCs starts to be represented in XML as ASN.1 <=> XML element-by-element
compatible data . Some day RP SW will stop convert back and forth and only work at the XML
level. If the push in XML persists, this is bound to happen, it is just when that is the question.
And in "the next round" the PKC itself _could_ actually be redefined from scratch in XML.
And even further down the road, ASN.1 PKC support is no longer "standard"!
Note: I am not _advocating_ this, I am merely pointing to what I have seen happening in other
sectors. Over and over again. EDI vs XML, IPX vs IP, Command-line vs GUI, Leased lines
vs Internet, etc , etc, etc,
> You are asking the wrong and too general question. It is not a question
> whether "whole PKIX should support XML". Would you re-define CMP and CMC to
> use XML? I suppose not.
Actually I have no idea on that at this point. It could happen once the ball gets rolling.
A pure market decision IMO. If these protocols (which I know rather little about)
have a wide usage, they could be _candidates_ at least.
For a company like yours (Entegrity), it could be important to actually jump on the
XML PKI bandwagon if only for marketing reasons. I guess you saw that Warwick
Ford of VeriSign supported a variant of XML ACs (S2ML).
Anders
Received: from marcellus.entegrity.se ([195.100.88.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18118 for <ietf-pkix@imc.org>; Mon, 20 Nov 2000 02:09:05 -0800 (PST)
Received: from cooper.entegrity.com ([10.0.0.123]) by marcellus.entegrity.se (8.9.3/8.9.3) with ESMTP id LAA11828; Mon, 20 Nov 2000 11:05:16 +0100 (MET)
Message-Id: <5.0.1.4.0.20001120103927.02ef7a10@exchsvr1.entegrity.com>
X-Sender: nada@exchsvr1.entegrity.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 20 Nov 2000 11:06:41 +0100
To: "Anders Rundgren" <anders.rundgren@telia.com>, "Michael Zolotarev" <mzolotarev@baltimore.com>, "Stephen Kent" <kent@bbn.com>
From: Nada Kapidzic Cicovic <nada@entegrity.com>
Subject: Re: Should PKIX protocols support XML well?
Cc: "PKIX-List" <ietf-pkix@imc.org>
In-Reply-To: <001501c052c3$df347030$0201a8c0@vincent.se>
References: <D44EACB40164D311BEF00090274EDCCAD8B319@sydneymail1.jp.zergo.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 08:31 AM 11/20/00 +0100, Anders Rundgren wrote:
>Michael,
>
> > Let me try to help all us, by asking once again to stop comparing oranges
> > and apples. Or I just cannot help myself not to mention my favorite "how to
> > use a spanner to hammer a screw into a brick wall".
>
>I don't think all (even in this list) think of ASN.1 vs XML, or ASN.1 vs
>EDI as comparing oranges
>and apples. Basically all three the offer a way to structure data objects.
Anders, I agree with Michael on this issue.
>I.e. the ONLY question left is (still) the subject of this message:
>
>========================================================
>Should PKIX support XML, or is the proper way to go ahead with PKIXML WG?
>========================================================
Have you not agreed with my last mail that PKCs should stay defined in
ASN.1/DER as they are?
Most of the discussions so far on the list was regarding ACs and possibly
some kind of remote certificate path building and verification protocols
being encoded in XML, so that non-ASN.1 aware clients can still use
existing PKI infrastructures. This is _not_ the whole PKIX, but a small
subset of it. That is exactly what Michael referred to as apples vs. oranges.
You are asking the wrong and too general question. It is not a question
whether "whole PKIX should support XML". Would you re-define CMP and CMC to
use XML? I suppose not.
Even if you decide to go with a separate WG it should not be called PKIXML,
since, in my opinion, it should not cover the whole work of PKIX, but only
a small subset. The name PKIXML implies replacing ASN.1 with XML for
everything, and that would be wrong and probably not very productive.
Nada
>According to the PKIX chair, the latter is the way to go.
>
>Anders
______________________________________________________________
Nada Kapidzic Cicovic, Ph.D.
Technical Director, Entegrity Solutions
office: + 46 8 477 77 37, cell: + 46 70 495 09 03, fax: + 46 8 477 77 31
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA25495 for <ietf-pkix@imc.org>; Sun, 19 Nov 2000 23:32:11 -0800 (PST)
Received: from mega (t5o69p45.telia.com [213.64.110.45]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id IAA12729; Mon, 20 Nov 2000 08:32:40 +0100 (CET)
Message-ID: <001501c052c3$df347030$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Michael Zolotarev" <mzolotarev@baltimore.com>, "Stephen Kent" <kent@bbn.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCAD8B319@sydneymail1.jp.zergo.com.au>
Subject: Re: Should PKIX protocols support XML well?
Date: Mon, 20 Nov 2000 08:31:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA25500
Michael,
> Let me try to help all us, by asking once again to stop comparing oranges
> and apples. Or I just cannot help myself not to mention my favorite "how to
> use a spanner to hammer a screw into a brick wall".
I don't think all (even in this list) think of ASN.1 vs XML, or ASN.1 vs EDI as comparing oranges
and apples. Basically all three the offer a way to structure data objects.
To be honest, I don't think that this discussion should be done purely on technical grounds
as it actually belongs to the same leage as
- Is Socialism better than Capitalism?
- Is Islam better than Christianty?
- or really heavy stuff such as: Is Britney Spears cuter than Christina Aguilera?
So if we must come to the conclusion which is best of ASN.1 or XML we will get nowhere as
the definition of "best" is not only a technical question. There is though a large body of people
that already have selected XML as their choice and they want to get something done now.
I.e. the ONLY question left is (still) the subject of this message:
========================================================
Should PKIX support XML, or is the proper way to go ahead with PKIXML WG?
========================================================
According to the PKIX chair, the latter is the way to go.
Anders
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01894 for <ietf-pkix@imc.org>; Sun, 19 Nov 2000 16:29:24 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA20929; Mon, 20 Nov 2000 10:36:55 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <W0XV18KN>; Mon, 20 Nov 2000 11:27:58 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCAD8B319@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Anders Rundgren <anders.rundgren@telia.com>, Stephen Kent <kent@bbn.com>
Cc: Michael Zolotarev <mzolotarev@baltimore.com>, PKIX-List <ietf-pkix@imc.org>
Subject: RE: Should PKIX protocols support XML well?
Date: Mon, 20 Nov 2000 11:27:51 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Anders,
Let me try to help all us, by asking once again to stop comparing oranges
and apples. Or I just cannot help myself not to mention my favorite "how to
use a spanner to hammer a screw into a brick wall".
ASN is not a replacement for hi-level EDI definitions. It is not, and has
been never meant to be used in purchase orders, or legal claims, or birthday
postcards dispatch notifications. The use of ASN1 is bound to a *wide* range
of environments where the scope is limited to a set of known and easily
categorizable (not sure there is such a word, though) cases. Like protocols
and PDU definitions.
You should not be saying that "XML is better then ASN1 because it suits some
environments better", referencing environments that don't use ASN1 anyway.
This argument doesn't serve the current discussion well. I suggest we
concentrate on 'XML vs ASN1' for the domains where ASN1 is dominant now, or
is currently anticipated to be used. Otherwise there is nothing to argue
about - that'd be just stupid to push ASN1 into the areas where the
advantages of XML are well recognised. Wise versa? That's a question to be
resolved.
And hopefully, once we define common grounds for the arguments, and
recognise that every approach has its rights and justifications, the whole
discussion will be reduced to just defining the boundaries. And
responsibilities.
Regards
M
> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Friday, 17 November 2000 20:32
> To: Stephen Kent
> Cc: Michael Zolotarev; PKIX-List
> Subject: Re: Should PKIX protocols support XML well?
>
>
> Here comes a major reason why ASN.1 did not make it as an
> EDI-replacent
> (unlike) XML.
>
> RoleSyntax ::= SEQUENCE {
> roleAuthority [0] GeneralNames OPTIONAL,
> roleName [1] GeneralName
> }
>
>
> name id-at-role
> OID { id-at 72 }
> syntax RoleSyntax
> values: Multiple allowed
>
> I.e. this connection between a structure (in the commercial
> world defined by customers)
> and an OID is based on an issued (requested) unique OID.
> There is no other programming
> language in the world that requires such measures. This is
> 100% Ok for (a limited set of)
> globally/widly recognizable things but totally useless for
> doing more or less local definitions.
>
> A Purchase Order in ASN.1 could require 20 _carefully
> managed_ OIDs while the same could be achived
> with a _single_ schema (=single registration).
>
> Note that schemas can _also_ support globally valid
> definitions with same "precision"
> as OIDs!
>
> I.e. except for the storage factor there is nothing that
> would make an XML-cert profile any
> less useful (or less trustworthy) than a X509 ditto.
>
> Anders
>
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA14829 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 19:24:40 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id QAA17672; Sat, 18 Nov 2000 16:31:40 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97451831006983>; Sat, 18 Nov 2000 16:31:50 (NZDT)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: pgut001@cs.auckland.ac.nz, rsalz@caveosystems.com
Subject: Re: OCSP identifiers
Cc: MMyers@verisign.com, ambarish@valicert.com, ietf-pkix@imc.org, kent@bbn.com
Sender: pgut001@cs.auckland.ac.nz
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 18 Nov 2000 16:31:50 (NZDT)
Message-ID: <97451831006983@kahu.cs.auckland.ac.nz>
Rich Salz <rsalz@caveosystems.com> writes:
>In a previous message I said that during work at a previous employer we
>determined that this violates a patent by Micali. I held my nose and did some
>searches this evening, and I believe I found it. Claims 37ff of US Patent
>5,717,757 filed Nov 96 and issued Feb 98:
>
> 37. A method for providing authenticated information about certificates,
> comprising the steps of:
> (a) receiving a request for information about a certificate including
> a proof that the certificate is issued;
> (b) verifying that the proof is valid; and
> (c) in response to the proof being valid, providing the requested
> information.
> 38. A method according to claim 37, wherein the proof includes providing
> an entire CA-authenticated certificate.
Oops, that had slipped my mind. In any case it's trivial to avoid, note the
wording:
> an entire CA-authenticated certificate.
"The pKCert shall consist of the certificate without the leading SEQUENCE and
length encoding"
Then it's not the entire CA-authenticated certificate any more, but it's
trivial to reconstruct it from that. The same thing is already being done for
public keys (you strip off the outer wrappers before hashing them) so it
shouldn't be a big deal.
Peter.
Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA12761 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 19:17:00 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 06717544; Fri, 17 Nov 2000 22:24:22 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-14-251.bellatlantic.net [141.154.14.251]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id WAA05712; Fri, 17 Nov 2000 22:24:46 -0500
Message-ID: <3A15F70C.C5E8CD0F@caveosystems.com>
Date: Fri, 17 Nov 2000 22:27:08 -0500
From: Rich Salz <rsalz@caveosystems.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pgut001@cs.auckland.ac.nz
CC: MMyers@verisign.com, ambarish@valicert.com, ietf-pkix@imc.org, kent@bbn.com
Subject: Re: OCSP identifiers
References: <97449976905185@kahu.cs.auckland.ac.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
> You can't get much simpler than a list of cert hashes and a status value...
If you want the OCSP responder to be able to work *only* off CRL's (e.g.,
Valicert -- arguably the OCSP market leader), then cert hash isn't very
useful.
> Probably the easiest option for everyone is to allow the pKCert ...
In a previous message I said that during work at a previous employer we
determined that this violates a patent by Micali. I held my nose and did some
searches this evening, and I believe I found it. Claims 37ff of US Patent
5,717,757 filed Nov 96 and issued Feb 98:
37. A method for providing authenticated information about certificates,
comprising the steps of:
(a) receiving a request for information about a certificate including
a proof that the certificate is issued;
(b) verifying that the proof is valid; and
(c) in response to the proof being valid, providing the requested
information.
38. A method according to claim 37, wherein the proof includes providing
an entire CA-authenticated certificate.
enjoy.
Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10175 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 17:12:49 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id RAA25376; Fri, 17 Nov 2000 17:22:02 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <XDTLA872>; Fri, 17 Nov 2000 17:20:29 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B723@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Michael Myers <MMyers@verisign.com>, Denis Pinkas <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org
Subject: OCSPv2 -01 draft
Date: Fri, 17 Nov 2000 17:20:29 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Below are the changes based on list comments. If I overlooked something,
please let me know.
Following the advice of Denis Pinkas, Peter Gutman, Margus Freudenthal and
others:
4.1.1 Request Syntax
---------------------
[added]
OCSPv2 servers SHALL recognize and respond to the certID option.
OCSPv2 client SHOULD recognize and respond to the certID option.
I amended the proposed ReqCert ASN.1 syntax to:
ReqCert ::= CHOICE {
certID CertID,
issuerSerial [0] IssuerandSerialNumber,
pKCert [1] Certificate,
name [2] GeneralName,
certhash [3] OCTET STRING }
based especially on Peter Gutman's analysis.
4.4.4 Archive Cutoff
---------------------
There was an issue on this wrt suspension but when I went back and looked at
the public comments it's not clear to me that we as a WG had closed on it.
Perhaps Carlin Covey would be willing to contribute text addressing this
requirement?
Mike
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13294 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 15:28:55 -0800 (PST)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP for <ietf-pkix@imc.org> id 615E415539; Fri, 17 Nov 2000 18:36:07 -0500 (EST)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 0DE257C0E8 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 18:36:07 -0500 (EST)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <WMP248ZF>; Fri, 17 Nov 2000 18:36:05 -0500
Message-ID: <AAD0807E1794D311A54000A0C99609B9165138@macertco-srv1.ma.certco.com>
From: "Tiernan, Tim" <tiernant@CertCo.com>
To: ietf-pkix@imc.org
Subject: unsubscribe
Date: Fri, 17 Nov 2000 18:36:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
unsubscribe
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24297 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 14:15:48 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id LAA03931; Sat, 18 Nov 2000 11:22:39 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97449976905185>; Sat, 18 Nov 2000 11:22:49 (NZDT)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: MMyers@verisign.com, ambarish@valicert.com, ietf-pkix@imc.org, margus@cyber.ee
Subject: RE: OCSP identifiers
Sender: pgut001@cs.auckland.ac.nz
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 18 Nov 2000 11:22:49 (NZDT)
Message-ID: <97449976905185@kahu.cs.auckland.ac.nz>
Ambarish Malpani <ambarish@valicert.com> writes:
>c. You want to be able to have an OCSP responder be very highly available. We
>have been able to provide very highly available and distributed solutions to
>people trying to do PKI deployments based on OCSP in part because the data
>that had to be replicated was very simple.
You can't get much simpler than a list of cert hashes and a status value...
when I said I'd support pKCert what I was really supporting was hash( pKCert ),
since it's trivial to turn it into the hashed form I didn't really distinguish
between the two. I'm certainly all in favour of the cert hash, but if people
insist on the unhashed pKCert I don't mind much either since all it involves is
a single hash operation by the server.
Probably the easiest option for everyone is to allow the pKCert and nothing
else and then let the server extract whatever it feels like (cert, hash(cert),
issuerAndSerialNumber, hash(issuer)+serialNumber, subjectKeyIdentifier, bit-
reversed DN with FFT of the keyUsage extension, or whatever else you want. It
may make the requests a tiny bit larger, but it does have the great advantage
that it'll keep everyone happy.
Peter.
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16649 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 13:46:22 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4600201VHY3J@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 17 Nov 2000 13:53:58 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G460013RVHYY6@ext-mail.valicert.com>; Fri, 17 Nov 2000 13:53:58 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NL9N0>; Fri, 17 Nov 2000 13:51:51 -0800
Content-return: allowed
Date: Fri, 17 Nov 2000 13:51:51 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: OCSP identifiers
To: "'Michael Myers'" <MMyers@verisign.com>, Margus Freudenthal <margus@cyber.ee>, ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E15302B@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Mike, as you might expect, I would like to raise "serious
objections" to this.
a. I don't think it is helping anybody be putting in a whole set
of methods of identifying certificates - you aren't making the
client application's life any easier and are making the server's
job harder. It will also result in more interop problems.
b. It is very, very valuable to be able to provide OCSP responses
off CRLs - they are a well defined format and enable us to work
with a bunch of different CAs
c. You want to be able to have an OCSP responder be very highly
available. We have been able to provide very highly available and
distributed solutions to people trying to do PKI deployments
based on OCSP in part because the data that had to be replicated
was very simple.
I am not sure whether this would encourage you or discourage you
from adding the certificate hash as an option, but I just thought
you might like to know.
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Michael Myers [mailto:MMyers@verisign.com]
> Sent: Friday, November 17, 2000 11:59 AM
> To: Margus Freudenthal; ietf-pkix@imc.org
> Subject: RE: OCSP identifiers
>
>
> Margus,
>
> We agree, especially regarding the observation that OCSP
> isn't and should't
> be tied to CRLs.
>
> I don't see any problem against including cert hash among
> OCSP's certificate
> identification options. Unless somebody raises a significant
> objection,
> I'll put it in.
>
> Mike
>
> > -----Original Message-----
> > From: Margus Freudenthal [mailto:margus@cyber.ee]
> > Sent: Friday, November 17, 2000 12:52 AM
> > To: ietf-pkix@imc.org
> > Subject: Re: OCSP identifiers
> >
> >
> > Peter Gutmann wrote:
> > >
> > > Hmm, it's going to need some profiling in order to reduce
> > the number of choices
> > > to a workable subset, I like the issuerSerial and pKCert options
> >
> > I would support including the certificate hash option as well. It
> > provides uniqueness despite the various key compromises.
> It is quite
> > short as well. I know, this doesn't allow CRL-based OCSP
> service, but
> > as the name implies OCSP should provide online service
> instead of CRL
> > caching.
> >
> >
> > --
> > Margus Freudenthal margus@cyber.ee
> > Cybernetica http://www.cyber.ee/
> >
>
Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA16577 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 11:55:15 -0800 (PST)
Received: (qmail 8024 invoked from network); 17 Nov 2000 20:02:53 -0000
Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 17 Nov 2000 20:02:53 -0000
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 17 Nov 2000 14:02:50 -0600
Message-ID: <3A158EC1.2798AEEE@nma.com>
Date: Fri, 17 Nov 2000 12:02:09 -0800
From: Ed Gerck <egerck@nma.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: Stephen Kent <kent@bbn.com>, Michael Zolotarev <mzolotarev@baltimore.com>, PKIX-List <ietf-pkix@imc.org>
Subject: Prolog? PKIA? Proposal, was Re: Should PKIX protocols support XML well?
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <v04220805b639c5cf2910@[128.33.238.64]> <009201c0507a$b1250740$0201a8c0@vincent.se> <014501c05081$9a3a2900$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote:
> I.e. except for the storage factor there is nothing that would make an XML-cert profile any
> less useful (or less trustworthy) than a X509 ditto.
This reminds me of the Prolog wars in AI. Is this WG really trying to block
XML-based X.509 certs on the basis that ASN.1 has some advantages in
terms of central control, while ignoring other advantages of XML? Well,
this WG is supposed to be PKI with X.509, not PKIA, as PKI with ASN.1.
Can we form a group within this WG to look into PKI with X.509, but encoded
in XML? Who knows, this may avoid us doing the same for PGP and actually
save us some work.
Cheers,
Ed Gerck
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15405 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 11:51:32 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA19852; Fri, 17 Nov 2000 11:55:14 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <W6GH8NZM>; Fri, 17 Nov 2000 11:59:07 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B70E@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Margus Freudenthal <margus@cyber.ee>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Fri, 17 Nov 2000 11:58:59 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Margus,
We agree, especially regarding the observation that OCSP isn't and should't
be tied to CRLs.
I don't see any problem against including cert hash among OCSP's certificate
identification options. Unless somebody raises a significant objection,
I'll put it in.
Mike
> -----Original Message-----
> From: Margus Freudenthal [mailto:margus@cyber.ee]
> Sent: Friday, November 17, 2000 12:52 AM
> To: ietf-pkix@imc.org
> Subject: Re: OCSP identifiers
>
>
> Peter Gutmann wrote:
> >
> > Hmm, it's going to need some profiling in order to reduce
> the number of choices
> > to a workable subset, I like the issuerSerial and pKCert options
>
> I would support including the certificate hash option as well. It
> provides uniqueness despite the various key compromises. It is quite
> short as well. I know, this doesn't allow CRL-based OCSP service, but
> as the name implies OCSP should provide online service instead of CRL
> caching.
>
>
> --
> Margus Freudenthal margus@cyber.ee
> Cybernetica http://www.cyber.ee/
>
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15340 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 11:51:22 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA19843; Fri, 17 Nov 2000 11:55:09 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <WZAJP4B4>; Fri, 17 Nov 2000 11:59:01 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B70F@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Denis Pinkas <Denis.Pinkas@bull.net>
Cc: ietf-pkix@imc.org
Subject: RE: DPV vs SCVP
Date: Fri, 17 Nov 2000 11:58:59 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Denis,
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Friday, November 17, 2000 12:36 AM
> To: Michael Myers
> Cc: Paul Hoffman / IMC; ietf-pkix@imc.org
> Subject: Re: DPV vs SCVP
>
>
> Michael,
>
> > Paul,
> >
> > The OCSPv2 draft does not propose a new protocol; it's an
> improvement to an
> > existing protocol.
>
> Obviously wrong.
This is what I was afraid of. I don't think it's productive to argue this
point. What's important is determining if the proposals are technically
correct and responsive to requirements.
> In the current proposal, there is no backward
> compatibility: OCSPv2 is a new protocol. The only big
> advantage for OSCPv2
> against SCVP would be some kind of backward compatibility with OCSPv1.
> Otherwise, since SCVP is also a new protocol, why not
> consider it (I mean
> its ASN.1 version, not its XML version) ?
I'm quite sure we're describing the same elephant.
> Before going to this extreme
> position, I would like to try to "save" OCSP, hence why I am
> spending (too
> much ?) energy on that topic.
The question is, do we wish to address these issues and briefly cycle
RFC2560 at proposed or simply address incremental corrections and move it
forward? Rough consensus appears to favor the former.
>
> > At its core it proposes alternative means of identifying
> > a certificate that are more in line with well-known needs.
>
> "Alternative", in this case, means different and thus
> non-compatible means.
The original v1 certID syntax is preserved in a backwards interoperable
fashion. But this discussion has yielded the correct effect. It's clear I
need to improve the draft more or less as follows as a proposal to the WG.
v1 servers SHALL support certID to ensure interoperability with v1 clients.
v2 clients SHOULD (SHALL?) be capable of supporting the original certID
structure.
>
> > It could be argued that the DPV and DPD drafts define a new
> protocol. But
> > since (and especially in the case of DPV) we're talking
> about little more
> > than extension OIDs, I fear that we'll get so wrapped up
> debating what is a
> > protocol vs. a protocol extension that we'll lose sight of
> the problem we're
> > trying to solve.
>
> DPV and DPD can only be considered as extensions, if you
> agree with the
> meaning of the status I explained in two E-mails sent to you.
> I am still
> awaiting a detailed response from you on this matter, and
> globally on my
> previous E-mail.
I had hoped that you considered my prior emails as responsive. Some of your
comments I didn't take to be actionable in the absence of a broader
consensus. I'll take another look at them today to see if I missed
something obvious.
>
> > BTW, all 2560 authors were asked if they wished to
> contribute at that same
> > level of cycle time committment on OCSPv2. The authorship
> list on the
> > OCSPv2 draft reflects the outcome of those invitations.
>
> Not open to invitations for others ? Is it a closed user group ?
Of course it's an open WG and as an IETF WG the technical contributions of
its participating members are key to the quality of the solutions that we
produce.
>
> > My response to Denis is simply me thinking that once we've
> achieved rough
> > consensus, running code and an RFC that the IETF has
> spoken. Else when is a
> > last call not a last call? When is rough consensus not
> rough consensus?
> > When is running code not running code? I look to the
> chairs to provide us
> > guidance on these points. Until then, that's my story and
> I'm sticking to
> > it.
>
> We are far from rough consensus at the time being.
Actually, I believe we are.
If what you're saying is, Denis' text wasn't recorded verbatim as proposed,
well, that's probably true. Much of the text I propose isn't recorded
verbatim either. But your comments nonetheless have yeilded positive impact
on this technical improvement to an Internet standard. And after all, isn't
that why we do what we do?
> If you
> continue to stick
> on your positions, I will be inclined to agree with Paul: "
> If the author of
> a document is not willing to work within the IETF framework,
> maybe it is
> time for a different author or additional co-authors". We
> need to move up.
As I tried to say, I am doing all I can to fully enable the IETF process on
this issue. This includes a healthy respect for the consensus development
process. That in turn leads me to conclude that once a WG has gone through
the pain of developing a consensus-based position, those efforts should be
respected in the interests of maintaining our forward progress.
And as I tried to say, I'm happy to be guided towards an alternative
understanding. But it's my sense that once the IETF makes a decision that
leads to an RFC, we should be very cautious in recanting on those
recommendations. For example, some of my earliest OCSP drafts advocated for
a non-ASN.1 syntax because doing so benefits development, debugging and
deployment, as Khaja recently and so well put it. The WG decided that it
wanted an ASN.1-based solution. We made that decision and moved on.
It's my opinion that we must think through a reset of the "good" and
"unknown" status responses very carefully because of what it implies upon
the IETF process. It's possible however that my opinion is unique among
IETF members. If so and knowning that, I look to the chairs for guidance to
help me ensure that the IETF process is fully respected as we go forward on
this obviously vital issue.
>
> Denis
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05248 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 10:48:50 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA21755; Sat, 18 Nov 2000 07:56:10 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97448738004175>; Sat, 18 Nov 2000 07:56:20 (NZDT)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: ietf-pkix@imc.org, michael@stroeder.com
Subject: Re: Should PKIX protocols support XML well?
Sender: pgut001@cs.auckland.ac.nz
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 18 Nov 2000 07:56:20 (NZDT)
Message-ID: <97448738004175@kahu.cs.auckland.ac.nz>
Michael StrM-vder <michael@stroeder.com> writes:
>Paul Koning wrote:
>>Absolutely. This is the classic rule "be strict in what you send,
>>lenient in what you receive."
>1. But if you are strict with what you receive you can influence other
>implementors to be compliant because they might try to test their
>implementations and data against your lib.
No, it has no effect at all. The number of broken certificates has stayed more
or less constant in the three-odd years in which I've been maintaining the
X.509 style guide as new CAs and implementations appear, and it's really going
to explode if PKIs ever take off. In addition you've got legacy certs and
chains with CAs with 20-year validity periods which will be around
(effectively) forever. The problem of broken certs will never go away, and
it's not getting any better either.
>2. You might get unexpected and unsecure behaviour of your own application
>when accepting certificates not compliant to PKIX specs.
Sure, but when users come to you and say "Your code is broken, it doesn't
accept this cert" and you tell them "Well actually the cert doesn't comply with
section 4, subsection 2, paragraph 4, clause 8(b) of RFC 2459" they'll just
find a vendor whose code doesn't reject the cert (this is one reason why I went
and back-patched my code to accept all sorts of rubbish, because if you present
users with a safety warning they'll respond by disabling the warning or finding
something which doesn't warn them).
Peter.
Received: from junker.ms.inka.de (xli.yapay.inka.de [212.227.14.169]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03509 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 10:18:39 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 51831683C7; Fri, 17 Nov 2000 08:20:53 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A14DC54.8A1EB912@stroeder.com>
Date: Fri, 17 Nov 2000 08:20:52 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Frank Balluffi <frankb@valicert.com>
Cc: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <613B3C619C9AD4118C4E00B0D03E7C3E136663@exchange.valicert.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Frank Balluffi wrote:
>
> Rich,
>
> If RFC 2459 says:
>
> The serial number is an integer assigned by the CA to each
> certificate. It MUST be unique for each certificate issued by a
> given CA (i.e., the issuer name and serial number identify a unique
> certificate).
>
> why are issuer + serial number, and issuer + subject + serial number not
> unique? Is this an example of reality not agreeing with theory?
As I understand it Denis pointed out that this might not be unique
in case of a issuer key compromise (and the issuer DN being reused
in the new issuer cert).
IMHO it should be forbidden to reuse the issuer DN in this serious
case anyway.
Ciao, Michael.
Received: from junker.ms.inka.de (xli.yapay.inka.de [212.227.14.169]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03508 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 10:18:38 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id E1320683C5 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 07:55:40 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A14D66C.774159D0@stroeder.com>
Date: Fri, 17 Nov 2000 07:55:40 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: Should PKIX protocols support XML well?
References: <97431154424428@kahu.cs.auckland.ac.nz> <3A13CB26.6563D3E4@asn-1.com> <14867.62366.252251.866493@pkoning.ironstream.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Paul Koning wrote:
>
> Absolutely. This is the classic rule "be strict in what you send,
> lenient in what you receive."
1. But if you are strict with what you receive you can influence
other implementors to be compliant because they might try to test
their implementations and data against your lib.
2. You might get unexpected and unsecure behaviour of your own
application when accepting certificates not compliant to PKIX specs.
Ciao, Michael.
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00869 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 09:31:12 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA09163; Fri, 17 Nov 2000 12:15:27 -0500 (EST)
Message-Id: <200011171715.MAA09159@roadblock.missi.ncsc.mil>
Date: Fri, 17 Nov 2000 12:30:59 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: Extended Key Usage and path validation
To: dpkemp@missi.ncsc.mil, kent@bbn.com
Cc: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=ISO-8859-1
Content-MD5: 10NOOiPj+NfD/PHaBBbtdA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id JAA00871
Steve,
That's the problem with the English language - I used "applications"
in two different senses in the same message, and realized my error
just after hitting "send".
I see two possibilities in your example. If you mean the application
is "Internet Backbone Management", then I agree that CP is the correct
extension. S-BGP nodes may be the only planned application of such
certificates, but in the future, the certs might be used for https
connections supporting Internet Management.
But if you mean that the application is "the S-BGP protocol", then I
believe EKU is more appropriate than CP. S-BGP equipment could require
the presence of an EKU, but it can't require the presence of an
"Internet Management" CP because the equipment might have been
purchased for use in a non-Internet-management environment.
What I should have said is that CP is nearly unrelated to the
protocol which makes use of the certificate.
Regards,
Dave
> Date: Thu, 16 Nov 2000 14:04:43 -0500
> To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
> From: Stephen Kent <kent@bbn.com>
> Subject: Re: Extended Key Usage and path validation
> Cc: ietf-pkix@imc.org
>
> David,
>
> >I agree with Patrick Patterson and Michael Ströder that using the
> >Certificate Policies extension to control usage of the EE key
> >"messes with" the CP extension. The policy under which certificates
> >are issued seems tenuously related, if not completely unrelated,
> >to the applications which make use of the certificates.
>
> There may be examples where the two are aligned. For example, in the
> S-BGP context, we anticipate defining a CP that clearly restricts the
> certs issued by registries to be used for S-BGP, as a means of
> limiting liability. But, I won't claim that this is a common case.
>
> Steve
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23238 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 07:37:50 -0800 (PST)
Received: from mega (t7o69p43.telia.com [213.65.46.43]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id QAA00197; Fri, 17 Nov 2000 16:45:19 +0100 (CET)
Message-ID: <01ad01c050ad$3289a660$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>, "Nada Kapidzic Cicovic" <nada@entegrity.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <v04220805b639c5cf2910@[128.33.238.64]> <5.0.1.4.0.20001117151935.02d63690@exchsvr1.entegrity.com>
Subject: Re: Should PKIX protocols support XML well?
Date: Fri, 17 Nov 2000 16:43:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA23248
Hi Nada,
Nice to see another Swede make it to the list!
> >Now you are addressing a core issue. If "we" becomes as I (but not you)
> >assume,
> >a wider definition than "a few IETF-hacks" the OID scheme will not look
> >that good
> >anymore. I am now talking about ACs and similar stuff (not PKCs) with a
> >potentilly high
> >application-specific (customer-defined) content.
>
>
> This is not the best approach in making standards. We are having problems
> with building inter-operable solutions with current uniquely identified
> structures. If we add ambiguity in their naming and identification, that
> will just add more deployment problems.
To take it from the e-business sector: Standards can be as deep or as thin
as required by the target. SOAP, BizTalk do not specify content, they specify
protocols and place-holders. This make sense for same apps. Then specific
messages are "standardized" (or not) depending on requirements.
For ACs (_____not_____ PKCs) I would like to enhance the container concept one step further.
But also switch to XML which is better suited for that purpose IMO (but not in some
others opinion). To "standardize" the representation of _some_ attributes you know
of (like in AC), is like if Microsoft would try to define suitable elements in "Purchase Orders".
They did not. And for a reason. It does not work!
Note: Not a _single_ person have claimed that they will create a _universal_ AC application (.EXE).
What does this say? That ACs really are _exactly_ as application-specific as I claim.
SW ,manufacturers will though provide frameworks, toolboxes etc.
Using XML schemas the framework will be hardly anything as it will re-use the XML parser
that is already in place. I expect the framework to be standard as well.
> >The distributed approach (like CAs) cannot guarantee any track record,
> >it will be organization-specific. Freedom has its price...
> >And a lot of people are prepared to pay for that. In some way or another.
>
> Does this mean even if they end up having proprietary solutions? Why then
> making a standard in the first place? For very application specific
> customer defined parts we almost do not need standards.
We need (or will get) a multi-level standard. At the top (IETF and others) we
have basic technology. At the next step we have local, national, global, or
community-based profiles of various dignity.
>However, for PKCs I hope we all agree that we do.
Agreed 1000000% ! Me exaggerate?
PKCs, LDAP objects and CRLs, will probably continue to be _defined_ in ASN.1 _forever_. But they will also
be represented in XML in as BASE64 and as XML<=>ASN.1 element-by-element compatible data.
Regards
Anders
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15937 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 06:40:35 -0800 (PST)
Received: from mega (t2o69p50.telia.com [62.20.144.170]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id PAA17385; Fri, 17 Nov 2000 15:48:01 +0100 (CET)
Message-ID: <018301c050a5$32a405d0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Frank Balluffi" <frankb@valicert.com>, "Stephen Kent" <kent@bbn.com>
Cc: "Michael Zolotarev" <mzolotarev@baltimore.com>, "PKIX-List" <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E136666@exchange.valicert.com>
Subject: Re: Should PKIX protocols support XML well?
Date: Fri, 17 Nov 2000 15:46:37 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA15938
Frank,
> I disagree. There is no reason why two people could not write ASN.1-based
> software:
>
> 1. that takes its object identifier values from command-line arguments or an
> initialization file, and
> 2. dynamically agree upon the value of each object identifier before they
> commence communication (i.e., not through some central registration process)
None of these alternatives sound particularly intriguing or fail-proof.
<snip>
> For example, ASN.1 is very effective at
> transmitting RSA public keys over a wire. XML is very effective at
> transmitting display-independent data over a wire.
XML is also when augmented with schemas an excellent way to create customized
data exchange objects like business messages, or to take something closer to
the hart of this community, attributes of a secure attribute container => XML-AC.
Exactlly how this will be carried out will be discussed in the PKIXML WG.
Anders
Received: from jlc.net (3ff83a80.dsl.flashcom.net [63.248.58.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15348 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 06:30:57 -0800 (PST)
Received: (from pkoning@localhost) by jlc.net (8.9.3/8.8.7) id JAA13454; Fri, 17 Nov 2000 09:38:34 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14869.17129.684502.473221@pkoning.ironstream.com>
Date: Fri, 17 Nov 2000 09:38:33 -0500 (EST)
From: Paul Koning <pkoning@ironstream.com>
To: anders.rundgren@telia.com
Cc: kent@bbn.com, mzolotarev@baltimore.com, ietf-pkix@imc.org
Subject: Re: Should PKIX protocols support XML well?
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <v04220805b639c5cf2910@[128.33.238.64]> <009201c0507a$b1250740$0201a8c0@vincent.se> <014501c05081$9a3a2900$0201a8c0@vincent.se>
X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid
>>>>> "Anders" == Anders Rundgren <anders.rundgren@telia.com> writes:
Anders> Here comes a major reason why ASN.1 did not make it as an
Anders> EDI-replacent (unlike) XML.
Anders>...
Anders> I.e. this connection between a structure (in the commercial
Anders> world defined by customers) and an OID is based on an issued
Anders> (requested) unique OID. There is no other programming
Anders> language in the world that requires such measures. This is
Anders> 100% Ok for (a limited set of) globally/widly recognizable
Anders> things but totally useless for doing more or less local
Anders> definitions.
Anders> A Purchase Order in ASN.1 could require 20 _carefully
Anders> managed_ OIDs while the same could be achived with a _single_
Anders> schema (=single registration).
I get the feeling you aren't familiar with Vendor MIBs in SNMP. It is
perfectly straightforward to do "more or less local definitions".
In order to describe 20 different things, you need 20 carefully
managed handles to distinguish them. That's going to be true no
matter what descriptive technology you use. The only difference will
be in syntax and in the flexibility of how those handles are assigned.
With OIDs, if you need to define locally managed things, you get a
Vendor OID from IANA, then you put things underneath that. No
Problem...
paul
Received: from marcellus.entegrity.se ([195.100.88.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14592 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 06:23:47 -0800 (PST)
Received: from cooper.entegrity.com ([10.0.0.123]) by marcellus.entegrity.se (8.9.3/8.9.3) with ESMTP id PAA15886; Fri, 17 Nov 2000 15:27:12 +0100 (MET)
Message-Id: <5.0.1.4.0.20001117151935.02d63690@exchsvr1.entegrity.com>
X-Sender: nada@exchsvr1.entegrity.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 17 Nov 2000 15:28:39 +0100
To: "Anders Rundgren" <anders.rundgren@telia.com>, "Stephen Kent" <kent@bbn.com>
From: Nada Kapidzic Cicovic <nada@entegrity.com>
Subject: Re: Should PKIX protocols support XML well?
Cc: "PKIX-List" <ietf-pkix@imc.org>
In-Reply-To: <009201c0507a$b1250740$0201a8c0@vincent.se>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <v04220805b639c5cf2910@[128.33.238.64]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA14594
At 10:42 AM 11/17/00 +0100, Anders Rundgren wrote:
>Steve,
>
> > I am obviously ignorant of the means by which XML schemas are
> > assigned globally unique names to avoid the collision problems
> > alluded to in other messages. Coould you explain how that works? Is
> > it hierarchic like OID and DNS, or is it complete distributed and
> > probabilistic in its collision avoidance, like some certificate
> > serial number assignment schemes we've learned about?
>
>I would be a liar if I said that _I_ have the solution to name collisions but
>if you build it on DNS-based URIs you at least have a sound
>foundation. Then it is
>not really a technical problem but an administrative one. I am *sure*
>that there
>will be name collÃsions but they will only occurr within an organization
>(=DNS-name) itself
>If that organization is VISA, sorry, it is their problem not ours. In the
>same way as
>CAs must keep track of what they do.
>
> > We know how to manage OIDs, and we have considerable experience in
> > doing it for several years.
>
>Now you are addressing a core issue. If "we" becomes as I (but not you)
>assume,
>a wider definition than "a few IETF-hacks" the OID scheme will not look
>that good
>anymore. I am now talking about ACs and similar stuff (not PKCs) with a
>potentilly high
>application-specific (customer-defined) content.
This is not the best approach in making standards. We are having problems
with building inter-operable solutions with current uniquely identified
structures. If we add ambiguity in their naming and identification, that
will just add more deployment problems.
> >I presume that an XML approach to solving
> > the problem has less of a track record, although that does not mean
> > it may not become equally viable in the future.
>
>The distributed approach (like CAs) cannot guarantee any track record,
>it will be organization-specific. Freedom has its price...
>And a lot of people are prepared to pay for that. In some way or another.
Does this mean even if they end up having proprietary solutions? Why then
making a standard in the first place? For very application specific
customer defined parts we almost do not need standards. However, for PKCs I
hope we all agree that we do.
Nada
>Anders
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA11104 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 05:06:15 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4600M017F1NZ@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 17 Nov 2000 05:13:49 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4600M4T7F06J@ext-mail.valicert.com>; Fri, 17 Nov 2000 05:13:48 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NL7R0>; Fri, 17 Nov 2000 05:11:43 -0800
Content-return: allowed
Date: Fri, 17 Nov 2000 05:11:42 -0800
From: Frank Balluffi <frankb@valicert.com>
Subject: RE: Should PKIX protocols support XML well?
To: "'Anders Rundgren'" <anders.rundgren@telia.com>, Stephen Kent <kent@bbn.com>
Cc: Michael Zolotarev <mzolotarev@baltimore.com>, PKIX-List <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E136666@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Anders,
I disagree. There is no reason why two people could not write ASN.1-based
software:
1. that takes its object identifier values from command-line arguments or an
initialization file, and
2. dynamically agree upon the value of each object identifier before they
commence communication (i.e., not through some central registration process)
ASN.1 does not have a monopoly on hard-coded identifiers!
Yesterday, Peter Lipp made some excellent points, including a discussion
about purity. I like the idea of diversity and am skeptical of anyone
preaching pure anything (i.e., extremism). ASN.1 is a terrific tool for
solving certain problems. So is XML. For example, ASN.1 is very effective at
transmitting RSA public keys over a wire. XML is very effective at
transmitting display-independent data over a wire. I am not implying that
XML can not be effectively used to solve other problems.
Frank
> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Friday, November 17, 2000 5:32 AM
> To: Stephen Kent
> Cc: Michael Zolotarev; PKIX-List
> Subject: Re: Should PKIX protocols support XML well?
>
>
> Here comes a major reason why ASN.1 did not make it as an
> EDI-replacent
> (unlike) XML.
>
> RoleSyntax ::= SEQUENCE {
> roleAuthority [0] GeneralNames OPTIONAL,
> roleName [1] GeneralName
> }
>
>
> name id-at-role
> OID { id-at 72 }
> syntax RoleSyntax
> values: Multiple allowed
>
> I.e. this connection between a structure (in the commercial
> world defined by customers)
> and an OID is based on an issued (requested) unique OID.
> There is no other programming
> language in the world that requires such measures. This is
> 100% Ok for (a limited set of)
> globally/widly recognizable things but totally useless for
> doing more or less local definitions.
>
> A Purchase Order in ASN.1 could require 20 _carefully
> managed_ OIDs while the same could be achived
> with a _single_ schema (=single registration).
>
> Note that schemas can _also_ support globally valid
> definitions with same "precision"
> as OIDs!
>
> I.e. except for the storage factor there is nothing that
> would make an XML-cert profile any
> less useful (or less trustworthy) than a X509 ditto.
>
> Anders
>
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26063 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 02:25:46 -0800 (PST)
Received: from mega (t5o69p73.telia.com [213.64.110.73]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id LAA28478; Fri, 17 Nov 2000 11:33:15 +0100 (CET)
Message-ID: <014501c05081$9a3a2900$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>
Cc: "Michael Zolotarev" <mzolotarev@baltimore.com>, "PKIX-List" <ietf-pkix@imc.org>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <v04220805b639c5cf2910@[128.33.238.64]> <009201c0507a$b1250740$0201a8c0@vincent.se>
Subject: Re: Should PKIX protocols support XML well?
Date: Fri, 17 Nov 2000 11:31:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA26064
Here comes a major reason why ASN.1 did not make it as an EDI-replacent
(unlike) XML.
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
name id-at-role
OID { id-at 72 }
syntax RoleSyntax
values: Multiple allowed
I.e. this connection between a structure (in the commercial world defined by customers)
and an OID is based on an issued (requested) unique OID. There is no other programming
language in the world that requires such measures. This is 100% Ok for (a limited set of)
globally/widly recognizable things but totally useless for doing more or less local definitions.
A Purchase Order in ASN.1 could require 20 _carefully managed_ OIDs while the same could be achived
with a _single_ schema (=single registration).
Note that schemas can _also_ support globally valid definitions with same "precision"
as OIDs!
I.e. except for the storage factor there is nothing that would make an XML-cert profile any
less useful (or less trustworthy) than a X509 ditto.
Anders
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22469 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 01:36:12 -0800 (PST)
Received: from mega (t5o69p119.telia.com [213.64.110.119]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id KAA19855; Fri, 17 Nov 2000 10:43:47 +0100 (CET)
Message-ID: <009201c0507a$b1250740$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <v04220805b639c5cf2910@[128.33.238.64]>
Subject: Re: Should PKIX protocols support XML well?
Date: Fri, 17 Nov 2000 10:42:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA22473
Steve,
> I am obviously ignorant of the means by which XML schemas are
> assigned globally unique names to avoid the collision problems
> alluded to in other messages. Coould you explain how that works? Is
> it hierarchic like OID and DNS, or is it complete distributed and
> probabilistic in its collision avoidance, like some certificate
> serial number assignment schemes we've learned about?
I would be a liar if I said that _I_ have the solution to name collisions but
if you build it on DNS-based URIs you at least have a sound foundation. Then it is
not really a technical problem but an administrative one. I am *sure* that there
will be name collÃsions but they will only occurr within an organization (=DNS-name) itself
If that organization is VISA, sorry, it is their problem not ours. In the same way as
CAs must keep track of what they do.
> We know how to manage OIDs, and we have considerable experience in
> doing it for several years.
Now you are addressing a core issue. If "we" becomes as I (but not you) assume,
a wider definition than "a few IETF-hacks" the OID scheme will not look that good
anymore. I am now talking about ACs and similar stuff (not PKCs) with a potentilly high
application-specific (customer-defined) content.
>I presume that an XML approach to solving
> the problem has less of a track record, although that does not mean
> it may not become equally viable in the future.
The distributed approach (like CAs) cannot guarantee any track record,
it will be organization-specific. Freedom has its price...
And a lot of people are prepared to pay for that. In some way or another.
Anders
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA15370 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 00:42:04 -0800 (PST)
Received: from kiku.itsise (kiku.itsise [192.168.2.2]) by atsgw.cyber.ee (8.11.1/8.11.1) with ESMTP id eAH8ngS11028 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 10:49:42 +0200
Received: from cyber.ee (dino.itsise [192.168.2.137]) by kiku.itsise (8.9.1a/8.9.1) with ESMTP id KAA05226 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 10:49:00 +0200
Message-ID: <3A14F1AB.3A44E17A@cyber.ee>
Date: Fri, 17 Nov 2000 10:51:55 +0200
From: Margus Freudenthal <margus@cyber.ee>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <97442381500582@kahu.cs.auckland.ac.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Gutmann wrote:
>
> Hmm, it's going to need some profiling in order to reduce the number of choices
> to a workable subset, I like the issuerSerial and pKCert options
I would support including the certificate hash option as well. It
provides uniqueness despite the various key compromises. It is quite
short as well. I know, this doesn't allow CRL-based OCSP service, but
as the name implies OCSP should provide online service instead of CRL
caching.
--
Margus Freudenthal margus@cyber.ee
Cybernetica http://www.cyber.ee/
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13237; Fri, 17 Nov 2000 00:28:57 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA31256; Fri, 17 Nov 2000 09:42:32 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA21308; Fri, 17 Nov 2000 09:36:00 +0100
Message-ID: <3A14EDF4.25131912@bull.net>
Date: Fri, 17 Nov 2000 09:36:04 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <MMyers@verisign.com>
CC: Paul Hoffman / IMC <phoffman@imc.org>, ietf-pkix@imc.org
Subject: Re: DPV vs SCVP
References: <2F3EC696EAEED311BB2D009027C3F4F401C5B6AB@vhqpostal.verisign.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael,
> Paul,
>
> The OCSPv2 draft does not propose a new protocol; it's an improvement to an
> existing protocol.
Obviously wrong. In the current proposal, there is no backward
compatibility: OCSPv2 is a new protocol. The only big advantage for OSCPv2
against SCVP would be some kind of backward compatibility with OCSPv1.
Otherwise, since SCVP is also a new protocol, why not consider it (I mean
its ASN.1 version, not its XML version) ? Before going to this extreme
position, I would like to try to "save" OCSP, hence why I am spending (too
much ?) energy on that topic.
> At its core it proposes alternative means of identifying
> a certificate that are more in line with well-known needs.
"Alternative", in this case, means different and thus non-compatible means.
> It could be argued that the DPV and DPD drafts define a new protocol. But
> since (and especially in the case of DPV) we're talking about little more
> than extension OIDs, I fear that we'll get so wrapped up debating what is a
> protocol vs. a protocol extension that we'll lose sight of the problem we're
> trying to solve.
DPV and DPD can only be considered as extensions, if you agree with the
meaning of the status I explained in two E-mails sent to you. I am still
awaiting a detailed response from you on this matter, and globally on my
previous E-mail.
> BTW, all 2560 authors were asked if they wished to contribute at that same
> level of cycle time committment on OCSPv2. The authorship list on the
> OCSPv2 draft reflects the outcome of those invitations.
Not open to invitations for others ? Is it a closed user group ?
> My response to Denis is simply me thinking that once we've achieved rough
> consensus, running code and an RFC that the IETF has spoken. Else when is a
> last call not a last call? When is rough consensus not rough consensus?
> When is running code not running code? I look to the chairs to provide us
> guidance on these points. Until then, that's my story and I'm sticking to
> it.
We are far from rough consensus at the time being. If you continue to stick
on your positions, I will be inclined to agree with Paul: " If the author of
a document is not willing to work within the IETF framework, maybe it is
time for a different author or additional co-authors". We need to move up.
Denis
> Mike
>
> > -----Original Message-----
> > From: Paul Hoffman / IMC [mailto:phoffman@imc.org]
> > Sent: Thursday, November 16, 2000 8:46 AM
> > To: ietf-pkix@imc.org
> > Subject: RE: DPV vs SCVP
> >
> >
> > At 10:08 AM -0800 11/15/00, Michael Myers wrote:
> > >Replace "good" with "not revoked"
> > >---------------------------------
> > >The last call for comments on the I-D that led to RFC2560
> > occurred roughly
> > >two years ago.
> > >
> > >
> > >Replace "unknown" with "revocation status unknown"
> > >--------------------------------------------------
> > >See above.
> >
> > OCSPv2 is a new protocol, which means that bugs in the old protocol
> > can be fixed. I'm not saying that I agree with Denis' requests, but
> > it is inappropriate to give an out of hand rejection to them simply
> > because they had been discussed before, at the same time as the othe
> > flaws in OCSP were being considered.
> >
> > If the author of a document is not willing to work within the IETF
> > framework, maybe it is time for a different author or additional
> > co-authors, such as the ones who helped craft OCSPv1.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> >
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01716 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 23:16:37 -0800 (PST)
Received: from mega (t4o69p18.telia.com [62.20.145.138]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id IAA01921; Fri, 17 Nov 2000 08:24:13 +0100 (CET)
Message-ID: <005001c05067$317ca600$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <3A139374.B6BDD00E@nma.com> <009b01c04fa6$33b92130$0201a8c0@vincent.se> <v04220806b639c6a45afb@[128.33.238.64]>
Subject: Re: Should PKIX protocols support XML well?
Date: Fri, 17 Nov 2000 08:22:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA01721
> On the other hand, just because a technology is new, has some
> attractive features, and is hyped, that does not make it a success
> nor a necessary successor to other technologies. Java is nice, but
> it has not taken over as predicted. Then, there's WAP, for example.
Java has not "taken over" as you say but it is at least much more known, used
etc. than ASN.1 (at dev. level). And the same is valid for XML although being
pretty new.
>As for starting a new WG,I thought I addressed this question already.
This is one way to do this. Don't you see a risk of losing a lot of good people to
this new WG? I think this question is of such magnitude that it requires a
*descision* from the chairs and the members.
Or do you expect the XML-PKI WG to consist of me an a few other "kinky" developers?
Why not try to estimate how many of current PKIX:ers that would put their main focus
in the new WG?
Anders
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA29327 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 23:05:01 -0800 (PST)
Received: from mega (t4o69p33.telia.com [62.20.145.153]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id IAA22798; Fri, 17 Nov 2000 08:12:36 +0100 (CET)
Message-ID: <004a01c05065$9287dbb0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>
Cc: <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCAD5A06F@sydneymail1.jp.zergo.com.au> <001e01c04f87$a5558b40$0201a8c0@vincent.se> <v04220818b63a209273e6@[128.33.238.64]>
Subject: Re: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
Date: Fri, 17 Nov 2000 08:11:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA29332
Steve,
> >I told OS/2 "zelots" that Windows would win *years* before it
> >actually did. I was always
> >put down by their view that OS/2 was so much better, that Windows
> >would have no chance.
> >I said sure, but if it is not on most computers by default it will
> >stay marginal. In spite of
> >possible technical advantages.
>
> So, if you were willing to put you money where your mouth was long
> ago, I assume you invested heavily in MS, made lots of money, and
> thus your involvement in PKI technology is merely an avocation, right?
Unfortunately I did not invest a cent in MS. However, I have invested quite a
bit of time, money, and prestige in own PKI ventures and intend to make a fortune on that :-)
That's I why I am so keen on marketing issues like XML etc.
Anders
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA24878 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 22:35:52 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id QAA15803; Fri, 17 Nov 2000 16:50:55 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <W0XV17Y9>; Fri, 17 Nov 2000 17:41:44 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCAD5A758@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>, PKIX-List <ietf-pkix@imc.org>
Subject: RE: Should PKIX protocols support XML well?
Date: Fri, 17 Nov 2000 17:41:43 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
> With XML you can simply download e.g. a DTD from
> the URL in the XML data and use it to verify if the XML data is
> compliant to the schema.
And what after it? Does the application (knowing that the sctucture is Ok)
use the structure? If it does (why bother with verification otherwise?),
then the application must KNOW what's inside the structure, and pull the
values out of it. So that the XML application has to posess the same degree
of awareness of the actual content of the structure, as any other (ASN)
application.
The only difference is: you parse already knowing that what you are parsing
is all right (XML), or you parse and validate at the same time (ASN).
XML certianly does have its advantages over ASN. But schemas-based
validation doesn't necessarily present a convincing argument, compared to
the ASN1's way of structure validation.
M
Received: from burusomail.buruso.com ([211.58.242.8]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA22221 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 19:58:29 -0800 (PST)
Received: (from tomato [211.60.238.61]) by burusomail.buruso.com (Mail-Gear 1.1.0) with SMTP id M2000111713075923860 for <ietf-pkix@imc.org>; Fri, 17 Nov 2000 13:07:59 +0900
From: =?ks_c_5601-1987?B?v8C47byx?= <catseye@buruso.com>
To: <ietf-pkix@imc.org>
Subject:
Date: Fri, 17 Nov 2000 13:06:09 +0900
Message-ID: <HNELIAPIHDKGCPJCPKHAIELNCAAA.catseye@buruso.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id TAA22224
unsubscribe catseye@buruso.com
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20461 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 18:31:40 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4500K01E1HZ7@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 16 Nov 2000 18:39:17 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4500KFPE1HLH@ext-mail.valicert.com>; Thu, 16 Nov 2000 18:39:17 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NL6LQ>; Thu, 16 Nov 2000 18:37:12 -0800
Content-return: allowed
Date: Thu, 16 Nov 2000 18:35:15 -0800
From: Peter Williams <peterw@valicert.com>
Subject: RE: Should PKIX protocols support XML well?
To: "'Stephen Kent'" <kent@bbn.com>
Cc: PKIX-List <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E182B07@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Deferred-delivery: Thu, 16 Nov 2000 18:36:00 -0800
Ignorance abatement:
http://gca.org/whats_sgml/whats_sgml_regist_process.htm registration process
http://www.w3.org/TR/2000/REC-xml-20001006#dt-extent application to XML
http://www.ietf.org/rfc/rfc2732.txt URIs
An XML registry information page
http://www.oasis-open.org/cover/xmlRegistry.html
An example US military (SGML entity) registry: http://www.asrl.com/
Mcrosoft provision of XML infrastructure to fair percentage of the
Internet http://msdn.microsoft.com/xml/general/xmlparser.asp
-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Thursday, November 16, 2000 3:35 PM
To: Anders Rundgren
Cc: PKIX-List
Subject: Re: Should PKIX protocols support XML well?
Anders,
I am obviously ignorant of the means by which XML schemas are
assigned globally unique names to avoid the collision problems
alluded to in other messages. Coould you explain how that works? Is
it hierarchic like OID and DNS, or is it complete distributed and
probabilistic in its collision avoidance, like some certificate
serial number assignment schemes we've learned about?
We know how to manage OIDs, and we have considerable experience in
doing it for several years. I presume that an XML approach to solving
the problem has less of a track record, although that does not mean
it may not become equally viable in the future.
Steve
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19433 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 17:49:28 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4500K01C35UZ@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 16 Nov 2000 17:57:05 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4500KC1C35LH@ext-mail.valicert.com>; Thu, 16 Nov 2000 17:57:05 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NL62R>; Thu, 16 Nov 2000 17:55:00 -0800
Content-return: allowed
Date: Thu, 16 Nov 2000 17:54:59 -0800
From: Frank Balluffi <frankb@valicert.com>
Subject: RE: OCSP identifiers
To: "'Rich Salz'" <rsalz@caveosystems.com>, ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E136663@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Rich,
If RFC 2459 says:
The serial number is an integer assigned by the CA to each
certificate. It MUST be unique for each certificate issued by a
given CA (i.e., the issuer name and serial number identify a unique
certificate).
why are issuer + serial number, and issuer + subject + serial number not
unique? Is this an example of reality not agreeing with theory?
Frank
> -----Original Message-----
> From: Rich Salz [mailto:rsalz@caveosystems.com]
> Sent: Wednesday, November 15, 2000 8:45 PM
> To: ietf-pkix@imc.org
> Subject: OCSP identifiers
>
>
> Be careful of sending the entire cert in a status or validity
> query. At a
> previous employer it became pretty clear (with a patent
> attorney) that this
> violated a patent held by Micali. No, I don't remember the
> number. But it was
> a good thing that the OCSP syntax changed from the -02 draft. :)
>
> As for what identifiers to use, I always thought that
> requiring the issuer's
> cert was onerous, and that sending the hash "for space
> reasons" was a bogus
> argument. I further agree with Gutmann that it required weird
> indices on the
> part of many implementors.
>
> I always thought {Issuer-DN, Subject-DN, Serial#} was
> relatively short and to
> the point and unique.
> /r$
>
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18519 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 17:09:48 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA11252; Fri, 17 Nov 2000 14:16:45 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97442381500582>; Fri, 17 Nov 2000 14:16:55 (NZDT)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: MMyers@verisign.com, pgut001@cs.auckland.ac.nz
Subject: RE: OCSP identifiers
Cc: ietf-pkix@imc.org
Sender: pgut001@cs.auckland.ac.nz
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 17 Nov 2000 14:16:55 (NZDT)
Message-ID: <97442381500582@kahu.cs.auckland.ac.nz>
Michael Myers <MMyers@verisign.com> writes:
>Your concern is precisely why the OCSPv2 draft proposes what it does. Have
>you any thoughts on the details of the relevant ASN.1?
Hmm, it's going to need some profiling in order to reduce the number of choices
to a workable subset, I like the issuerSerial and pKCert options but the certID
and name options are still going to cause problems on the server/responder side
(certID has the problems which have already been mentions, and something which
is a GeneralName could require creating a huge number of indices on the server
when a cert contains four email addresses, two URLs, a few extra DNs containing
stuff which didn't fit in the subject name, and some otherNames which didn't
fit anywhere else). How will interoperability be achieved? It'd require
either restricting clients to use the most useful/workable ID forms
(issuerSerial and possibly pKCert) or providing a mechanism whereby the server
can tell the client "I can't do anything with this, use the XXX identifier
instead".
Peter.
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17078 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 16:07:24 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id TAA00859; Thu, 16 Nov 2000 19:14:35 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v0422081eb63a268fdd28@[171.78.30.108]>
In-Reply-To: <14867.62366.252251.866493@pkoning.ironstream.com>
References: <97431154424428@kahu.cs.auckland.ac.nz> <3A13CB26.6563D3E4@asn-1.com> <14867.62366.252251.866493@pkoning.ironstream.com>
Date: Thu, 16 Nov 2000 19:07:27 -0500
To: Paul Koning <pkoning@ironstream.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well?
Cc: ietf-pkix@imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sorry guys, but I must disagree. Peter's lenient decoder is
appropriate for determining what's wrong with a wide range of
non-compliant certs, but it's a bad idea for any production system.
User's (and sys admins) are ill-prepared to deal with the complex
error indications that would arise if one reported what was wrong
with non-compliant certs and CRLs. if you don't report the errors,
they the designer of this "accommodating" software is making value
judgements about what might or might not be important. One is also
encouraging non-compliance, rather than providing feedback to vendors
who don't get it right.
Steve
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15870 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 15:34:02 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA26098; Thu, 16 Nov 2000 18:41:28 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v0422080eb639dfa04784@[128.33.238.64]>
In-Reply-To: <200011091639.LAA13549@roadblock.missi.ncsc.mil>
References: <200011091639.LAA13549@roadblock.missi.ncsc.mil>
Date: Thu, 16 Nov 2000 14:04:43 -0500
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Extended Key Usage and path validation
Cc: ietf-pkix@imc.org
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA15872
David,
>I agree with Patrick Patterson and Michael Ströder that using the
>Certificate Policies extension to control usage of the EE key
>"messes with" the CP extension. The policy under which certificates
>are issued seems tenuously related, if not completely unrelated,
>to the applications which make use of the certificates.
There may be examples where the two are aligned. For example, in the
S-BGP context, we anticipate defining a CP that clearly restricts the
certs issued by registries to be used for S-BGP, as a means of
limiting liability. But, I won't claim that this is a common case.
Steve
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15849 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 15:33:48 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA26090; Thu, 16 Nov 2000 18:41:23 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v0422080bb639cc86beaa@[128.33.238.64]>
In-Reply-To: <024f01c04f3d$7d631a20$0201a8c0@vincent.se>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]> <006701c04e5e$4891f030$0201a8c0@vincent.se> <007301c04ee9$360fde50$0201a8c0@vincent.se> <v04220804b6387bd1941e@[128.33.238.44]> <024f01c04f3d$7d631a20$0201a8c0@vincent.se>
Date: Thu, 16 Nov 2000 12:40:57 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well?
Cc: <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Anders,
>Steve,
>
> > If your goal is to create a competing technology serving the same
> > function as ACs, but based exclusively on XML, then I think it might
> > be appropriate to create a new WG. Contact the Security ADs.
>
>The goal is not to create a "competing" technolgy. But to build new
>exciting things
>on the platform that many believe has a better chance to become
>mainstream than the
>current one.
>
>The scope would certainly not be restricted to ACs, but it could be
>a good "starter".
We obviously define "competing" differently.
Steve
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15652 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 15:32:53 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25984; Thu, 16 Nov 2000 18:40:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04220806b639c6a45afb@[128.33.238.64]>
In-Reply-To: <009b01c04fa6$33b92130$0201a8c0@vincent.se>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <3A139374.B6BDD00E@nma.com> <009b01c04fa6$33b92130$0201a8c0@vincent.se>
Date: Thu, 16 Nov 2000 18:38:32 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well?
Cc: "PKIX-List" <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA15653
Anders,
>Just to prove my point.
>
>*outside* of this crummy list, Warwick Ford and others have no
>problems pushing XML
>for purposes that look *very* similar to PKIX's.
>
>http://www.netegrity.com/news/press_releases/dom/2000/press_release_1
>1_15b_00.html
>
>So what are we waiting on? To get redundant? Obsolete?
>
>Or give us a new WG!
>
The IETF and PKIX have no monopoly on good ideas. But we do adopt
scopes for WGs. I try to avoid duplicative efforts, something that
colors our current OCSP vs. SCVP debate. Overall, the IETF has not
been a diligent in this regard, in all areas.
On the other hand, just because a technology is new, has some
attractive features, and is hyped, that does not make it a success
nor a necessary successor to other technologies. Java is nice, but
it has not taken over as predicted. Then, there's WAP, for example.
As for starting a new WG,I thought I addressed this question already.
Steve
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15620 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 15:32:46 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25964; Thu, 16 Nov 2000 18:40:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04220805b639c5cf2910@[128.33.238.64]>
In-Reply-To: <003b01c04f9a$91b32ad0$0201a8c0@vincent.se>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se>
Date: Thu, 16 Nov 2000 18:35:25 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well?
Cc: "PKIX-List" <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Anders,
I am obviously ignorant of the means by which XML schemas are
assigned globally unique names to avoid the collision problems
alluded to in other messages. Coould you explain how that works? Is
it hierarchic like OID and DNS, or is it complete distributed and
probabilistic in its collision avoidance, like some certificate
serial number assignment schemes we've learned about?
We know how to manage OIDs, and we have considerable experience in
doing it for several years. I presume that an XML approach to solving
the problem has less of a track record, although that does not mean
it may not become equally viable in the future.
Steve
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15586 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 15:32:27 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25917; Thu, 16 Nov 2000 18:40:02 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04220802b639c29365c7@[128.33.238.64]>
In-Reply-To: <024901c04f3b$c777b5f0$0201a8c0@vincent.se>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]> <006701c04e5e$4891f030$0201a8c0@vincent.se> <v0422080fb637aa9c4f99@[171.78.30.108]> <005201c04ee0$9a2b8c80$0201a8c0@vincent.se> <v04220803b6387a794320@[128.33.238.44]> <024901c04f3b$c777b5f0$0201a8c0@vincent.se>
Date: Thu, 16 Nov 2000 18:34:05 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
Cc: <ietf-pkix@imc.org>
Content-Type: multipart/alternative; boundary="============_-1237704372==_ma============"
--============_-1237704372==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Anders,
>Steve,
>
> > >Using an XML schema you know when you are going to act on
>received data that:
> > >- The elements that the app "knows" are there. No more, no less
> > >- The elements have the proper format. I.e. no a 100k strings if
> > >the schema says 80
> >
> > This is also enforced by ASN.1 compiler-generated structure decoding
> > code, so there's no feature difference here.
>
>I know, but it is pretty to hard to do anything concering attributes
>already defined
>in the AC draft. I.e. if your app would like passwords to be max 80
>bytes you must perform this check at application-level (or rewriting AC).
>
>Using XML app-schemas you would not do that. Well, somebody have to write
>the app-schema. ONCE. And will contain just the stuff needed for that app.
>If the "ASN.1 camp" can do distributable app-shemas, fine. It is
>odd though that they
>currently don't except at laboratory level. The "XML camp" do this
>in production. Today.
Based on your comments, it seems that most of the differences you see
between ACs in ASN.1 and analogous structures in XML seems to hinge
on the question of when one defines syntax for the structures. The
two representations are obviously capable of supporting syntax agreed
to well in advance and adopted by many apps, or syntax that has more
app-specific scope. So, this does not appear to be a good basis for
distinguishing between the two.
Steve
--============_-1237704372==_ma============
Content-Type: text/enriched; charset="us-ascii"
Anders,
<excerpt>Steve,
> >Using an XML schema you know when you are going to act on received
data that:
> >- The elements that the app "knows" are there. No more, no less
> >- The elements have the proper format. I.e. no a 100k strings if
> >the schema says 80
>
> This is also enforced by ASN.1 compiler-generated structure decoding
> code, so there's no feature difference here.
I know, but it is pretty to hard to do anything concering attributes
already defined
in the AC draft. I.e. if your app would like passwords to be max 80
bytes you must perform this check at application-level (or rewriting
AC).
Using XML app-schemas you would not do that. Well, somebody have to
write
the app-schema. ONCE. And will contain just the stuff needed for that
app.
If the "ASN.1 camp" can do distributable app-shemas, fine. It is odd
though that they
currently don't except at laboratory level. The "XML camp" do this in
production. Today.
</excerpt>
Based on your comments, it seems that most of the differences you see
between ACs in ASN.1 and analogous structures in XML seems to hinge on
the question of <underline>when</underline> one defines syntax for the
structures. The two representations are obviously capable of supporting
syntax agreed to well in advance and adopted by many apps, or syntax
that has more app-specific scope. So, this does not appear to be a
good basis for distinguishing between the two.
Steve
--============_-1237704372==_ma============--
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14400 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 14:48:44 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id B0915683C5 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 23:46:33 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A1463C9.690EF389@stroeder.com>
Date: Thu, 16 Nov 2000 23:46:33 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: Should PKIX protocols support XML well?
References: <OF11437FCC.7FC0ACBB-ON85256999.00536274@iris.com> <3A1408F8.74DCDDE1@stroeder.com> <3A1419B3.7F6C8CFE@certplus.com> <3A14229D.E66C9559@stroeder.com> <14868.11813.731635.55034@pkoning.ironstream.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA14401
Paul Koning wrote:
>
> >>>>> "michael" == michael <=?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>> writes:
>
> michael> Jean-Marc Desperrier wrote:
> >> Michael Ströder wrote:
> >>
> >> > With XML you can simply download e.g. a DTD from the URL in
> >>
> >> Michael, you don't seem to realize that it's very difficult for
> >> many peoples to define an URL that is garanted to be persistent.
>
> michael> This very valid observation applies to every URI you store
> michael> in certificate extensions either.
>
> [..]
> Therefore URLs should never be used as pointers to data that is
> essential for the correct interpretation of the enclosing document.
> They should only be used to point to data that is merely informative.
Hmm. Now when validating a certificate where to get the current CRL
from if not from the location e.g. defined by a persistent URL?
If there's consensus here that URLs are not persistent please throw
away uniformResourceIdentifier (and all other options) in
GeneralName out of RFC2459 so that implementors don't have to worry
about useless details.
Ah, maybe we can keep otherName... ;-)
cRLDistributionPoints ::= {
CRLDistPointsSyntax }
CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF
DistributionPoint
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName
OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER}
Ciao, Michael.
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14353 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 14:47:23 -0800 (PST)
Received: from asn-1.com (user-2ivf08q.dialup.mindspring.com [165.247.129.26]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA17906 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 17:54:59 -0500 (EST)
Message-ID: <3A14474E.C2C312CF@asn-1.com>
Date: Thu, 16 Nov 2000 15:45:02 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
References: <D44EACB40164D311BEF00090274EDCCAD5A06F@sydneymail1.jp.zergo.com.au> <001e01c04f87$a5558b40$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote (in part):
>
> For market acceptance (=deployment) some people in this list do not share your views entirely.
>
> On a hard-core bit-level you are right. But you still don't have an ASN.1 schema and
> even if there is one, there is no support in my computer, nor in java AFAIK.
>
> When will you make this available? Will Bill put in W2K? Not a chance in hell!
>
Several Windows components use ASN.1 that may be on
your computer. The logon screen for Windows NT uses
ASN.1, as do Internet Explorer, Microsoft Netmeeting,
Microsoft Outlook. For example, if you go into IE,
click on Help, then About, then Licences, and scroll
down a little, you'll see that it uses ASN.1 tools
from OSS (Open Systems Solutions).
There are probably others as well. ASN.1 is very much
core technology. It is deployed so far down inside of
products that it doesn't get much notice.
Phil
----
Phillip H. Griffin Griffin Consulting
http://asn-1.com Secure ASN.1 Design & Implementation
+1-919-832-7008 1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14337 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 14:47:21 -0800 (PST)
Received: from asn-1.com (user-2ivf08q.dialup.mindspring.com [165.247.129.26]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA27346 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 17:54:57 -0500 (EST)
Message-ID: <3A144153.3A5A856B@asn-1.com>
Date: Thu, 16 Nov 2000 15:19:31 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well (XER)
References: <613B3C619C9AD4118C4E00B0D03E7C3E153006@exchange.valicert.com> <029701c04fe3$646401a0$0201a8c0@vincent.se> <3A140C40.82624DD2@certplus.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Jean-Marc
XER work (and workable alternative solutions) have
been and are being discussed on the asn1xml@oss.com
list. A NWI has been approved and work on ASN.1/XML
related issues is well underway. And it is not too
late to influence or to get involved in this effort.
But XER is not really a relevant PKIX topic.
Phil
Jean-Marc Desperrier wrote:
>
> Anders Rundgren wrote:
>
> > > The basic observation is that applications normally have a preferred
> > > format for data. If an application is doing everything in XML, that
> > > is likely to be their prefered format and they are likely to want
> > > their certificate validation protocol to be in that format, rather
> > > than another one.
> >
> > This is absolutely correct. So what do we do now to create this exciting new
> > XML-based PKI stuff? Create a new WG? Any suggestions?
> >
> > I personally do *not* believe Ãn creating dual track standards, as that would be a terrible
> > wast of talent and resources.
>
> It has been proposed that a XER (XML encoding rule) be defined.
>
> In fact I think it's even feasible to write a standard that can converts an ASN.1 definition,
> with incorporated constraints, to an equivalent DTD and schema.
>
> Together with a normalised XML representation, a document created using this DTD and schema
> would be the XER representation of the ASN.1, and could be created using standard XML tools
> that understands DTD/schema.
>
> We can have a convertion rule from OIDs to URI : for example as simple as "oid:1.3.6.1.5.5.7".
>
> The waste of ressources would be terribly reduced, because the standards themselves would be
> _not_ have to be rewritten if you want to do things in XML.
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11923 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 14:15:25 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id OAA16347; Thu, 16 Nov 2000 14:18:24 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <W6GH7SF2>; Thu, 16 Nov 2000 14:22:16 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B6AA@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: pgut001@cs.auckland.ac.nz
Cc: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Thu, 16 Nov 2000 14:22:15 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Peter,
Your concern is precisely why the OCSPv2 draft proposes what it does. Have
you any thoughts on the details of the relevant ASN.1?
Mike
> -----Original Message-----
> From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz]
> Sent: Thursday, November 16, 2000 10:45 PM
> To: ambarish@valicert.com; ietf-pkix@imc.org; rsalz@caveosystems.com
> Subject: RE: OCSP identifiers
>
>
> Ambarish Malpani <ambarish@valicert.com> writes:
>
> >Our definition for CertID when from:
> >
> >(Serial#, IssuerPKHash)
> >[which was my original suggestion]
> >
> >to
> >
> >(Serial#, IssuerPKHash, IssuerDN)
> >[because of a comment that Steve Kent had made saying that
> >responders might not index a CA's data based on its PKHash]
> >
> >to
> >(Serial#, IssuerPKHash, IssuerDNHash)
> >[because Mike Myers thought that the IssuerDN was too long to have
> >in the querry - Mike, please correct me if I have the reason wrong]
>
> I would really like to see this fixed, as I pointed out in my
> earlier message
> you can do something with the issuer name and serial number (which as
> issuerAndSerialNumber has been found perfectly adequate in
> the S/MIME world for
> years), you can work with hash( iAndS ) (since it's trivial
> to convert iAndS
> into the hashed form), but you can't do anything when one
> component is in a
> hashed form and the other one isn't (well, unless your
> implementation happens
> to use this mixture as a key). At the moment it's not
> possible for me to
> create an OCSP responder because it doesn't provide any
> useful/standard way to
> identify a cert.
>
> Peter.
>
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11781 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 14:14:57 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id OAA16379; Thu, 16 Nov 2000 14:18:34 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <W6GH7SFR>; Thu, 16 Nov 2000 14:22:26 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B6AC@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Ambarish Malpani <ambarish@valicert.com>, "'Rich Salz'" <rsalz@caveosystems.com>, ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Thu, 16 Nov 2000 14:22:15 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Ambarish,
> On Thursday, November 16, 2000 7:52 you wrote:
>
>[because Mike Myers thought that the IssuerDN was too long to have
> in the querry - Mike, please correct me if I have the reason wrong]
Basically, this is correct.
Abuse of DN content flexibility (I beleive Peter Gutmann produced an
existence proof on this point) may preclude the cachability of HTTP-based
OCSP responses for environments that wish to comply to Section 2.5 "Response
Pre-production" of RFC2560 due to the object size triggers of well-known
HTTP proxy servers.
I'm eager to hear from the HTTP proxy architects out there if this concern
remains well-founded. I'm assuming not.
Mike
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11754; Thu, 16 Nov 2000 14:14:45 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id OAA16365; Thu, 16 Nov 2000 14:18:31 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <WZAJPDVW>; Thu, 16 Nov 2000 14:22:20 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B6AB@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Paul Hoffman / IMC <phoffman@imc.org>, ietf-pkix@imc.org
Subject: RE: DPV vs SCVP
Date: Thu, 16 Nov 2000 14:22:15 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Paul,
The OCSPv2 draft does not propose a new protocol; it's an improvement to an
existing protocol. At its core it proposes alternative means of identifying
a certificate that are more in line with well-known needs.
It could be argued that the DPV and DPD drafts define a new protocol. But
since (and especially in the case of DPV) we're talking about little more
than extension OIDs, I fear that we'll get so wrapped up debating what is a
protocol vs. a protocol extension that we'll lose sight of the problem we're
trying to solve.
BTW, all 2560 authors were asked if they wished to contribute at that same
level of cycle time committment on OCSPv2. The authorship list on the
OCSPv2 draft reflects the outcome of those invitations.
My response to Denis is simply me thinking that once we've achieved rough
consensus, running code and an RFC that the IETF has spoken. Else when is a
last call not a last call? When is rough consensus not rough consensus?
When is running code not running code? I look to the chairs to provide us
guidance on these points. Until then, that's my story and I'm sticking to
it.
Mike
> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:phoffman@imc.org]
> Sent: Thursday, November 16, 2000 8:46 AM
> To: ietf-pkix@imc.org
> Subject: RE: DPV vs SCVP
>
>
> At 10:08 AM -0800 11/15/00, Michael Myers wrote:
> >Replace "good" with "not revoked"
> >---------------------------------
> >The last call for comments on the I-D that led to RFC2560
> occurred roughly
> >two years ago.
> >
> >
> >Replace "unknown" with "revocation status unknown"
> >--------------------------------------------------
> >See above.
>
> OCSPv2 is a new protocol, which means that bugs in the old protocol
> can be fixed. I'm not saying that I agree with Denis' requests, but
> it is inappropriate to give an out of hand rejection to them simply
> because they had been discussed before, at the same time as the othe
> flaws in OCSP were being considered.
>
> If the author of a document is not willing to work within the IETF
> framework, maybe it is time for a different author or additional
> co-authors, such as the ones who helped craft OCSPv1.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08347 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 13:04:31 -0800 (PST)
Received: from plipp [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id ADA71F4008E; Thu, 16 Nov 2000 22:12:07 +0100
From: "Peter Lipp" <plippml@iaik.at>
To: "ietf-pkix" <ietf-pkix@imc.org>
Subject: AW: Should PKIX protocols support XML well
Date: Thu, 16 Nov 2000 22:12:19 +0100
Message-ID: <OEEELKIFKJHGADBKOFPNIEGACBAA.plippml@iaik.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <031d01c05001$46c997e0$0201a8c0@vincent.se>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Folks,
having read through all these opinions, I'd concede that everybody is right
to some extend. I understand that many don't see the need to define
XML-format for things were ASN.1-solutions are available or seem better
suited. There may be more hype in XML than it's worth, but with major
commitment into XML from folks like e.g. Microsoft and many others, this is
unlikely to end. Now, I see the following two points that IMHO will make
somebody come up with XML-schemas for close-to-everything that existed in
ASN.1:
Purity:
I see folks that see no point in mixing different ways to do basically the
same things, if not unavoidable. Technical reasons for that may be
discussable, comparing the additional cost of an ASN.1 parser compared to an
XML-parser. Still, I can imagine some who simply want that. Maybe because
they don't want to understand ASN.1 after having learned XML. And at some
point you can't avoid learning some of it.
"Religion":
There are folks that strongly dislike XML and others that strongly hate
ASN.1.
Assuming that I am right and somebody comes up with say XML-certificates, to
choose the extreme example, the open question is if these developments will
be relevant. Don't know. But does it hurt if we start such an activity in
advance before such things happen? Yes, it would acknowledge that XML was
important, and push away from ASN.1 towards XML, which obviously is not
something many here want to see happen, for whatever reason.
If a move into that direction was bad, then XML-Signatures were a bad move
in the first place - why not use CMS - and it still has happened, ETSI
201.733 / XML is under development and XML-encryption is on its way. So,
lets go for it!
An open question to me is where it should happen. Either a new WG - joint WG
with W3C seems optimal - or maybe XMLDsig can take over?
>Poll Time?
I wonder if that's meaningful - in this WG :-) - but why not. Count this as
PRO.
Peter
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07180 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 12:44:41 -0800 (PST)
Received: from plipp [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A900750066; Thu, 16 Nov 2000 21:52:16 +0100
From: "Peter Lipp" <plippml@iaik.at>
To: "Eric Murray" <ericm@lne.com>, "PKIX-List" <ietf-pkix@imc.org>
Subject: AW: Should PKIX protocols support XML well?
Date: Thu, 16 Nov 2000 21:52:28 +0100
Message-ID: <OEEELKIFKJHGADBKOFPNCEGACBAA.plippml@iaik.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20001116090525.M26204@slack.lne.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>That sounds like a security problem. An attacker could modify
>the DTD that you download. So you need to either verify the
>integrity of the DTD, or authenticate its source, or both.
Correct. But this is nothing new, its like the root-cert - you need to have
the basic DTD's and schemas to startup in you local trusted store.
Peter
____________________
Dr. Peter Lipp
IAIK, TU Graz
Inffeldgasse 16a
A-8010 Graz
Phone: +43 316 873 5513
Fax: +43 316 873 5520
eMail: Peter.Lipp@iaik.at
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07170 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 12:44:39 -0800 (PST)
Received: from plipp [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A8F8750066; Thu, 16 Nov 2000 21:52:08 +0100
From: "Peter Lipp" <plippml@iaik.at>
To: "Denis Pinkas" <Denis.Pinkas@bull.net>
Cc: <ietf-pkix@imc.org>
Subject: AW: Should PKIX protocols support XML well
Date: Thu, 16 Nov 2000 21:52:20 +0100
Message-ID: <OEEELKIFKJHGADBKOFPNAEGACBAA.plippml@iaik.at>
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 IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3A14100C.48C9C8D0@bull.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Denis,
>Instead of asking the server to provide two sets of responses (i.e. one in
>ASN.1 and one in XML), a single response could be provided (ASN.1).
>[I already hear people saying XML, but remember the first argument, XML is
>far less compact]. This response could be translated, NOT into XML, but
>into the programming language being used (e.g. C or C ++).
That's what happens anyhow - at least in our implementation - when we parse
e.g. an ASN.1-structure. Well, it's a Java-Object, but thats conceptually
what you mean. I assume other ASN.1-software do the same. So do XML-parsers,
basically. And as you cannot transfer your "C or C++"-structure directly
over the wire, I don't see the point.
Peter
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22440 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 11:07:13 -0800 (PST)
Received: from mega (t1o69p49.telia.com [62.20.144.49]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id UAA10444; Thu, 16 Nov 2000 20:14:37 +0100 (CET)
Message-ID: <031d01c05001$46c997e0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Michael Zolotarev" <mzolotarev@baltimore.com>, "Ambarish Malpani" <ambarish@valicert.com>, "Denis Pinkas" <Denis.Pinkas@bull.net>, "ietf-pkix" <ietf-pkix@imc.org>, "Jean-Marc Desperrier" <jean-marc.desperrier@certplus.com>, <John_Wray@iris.com>, "Paul Koning" <pkoning@ironstream.com>, "Stephen Kent" <kent@bbn.com>, "David P. Kemp" <dpkemp@missi.ncsc.mil>, "Khaja Ahmed" <Khaja.Ahmed@identrus.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E153006@exchange.valicert.com> <029701c04fe3$646401a0$0201a8c0@vincent.se> <3A140C40.82624DD2@certplus.com>
Subject: Re: Should PKIX protocols support XML well
Date: Thu, 16 Nov 2000 20:11:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA22445
Jean-Marc et al.
> Together with a normalised XML representation, a document created using this DTD and schema
> would be the XER representation of the ASN.1, and could be created using standard XML tools
> that understands DTD/schema.
>
> We can have a convertion rule from OIDs to URI : for example as simple as "oid:1.3.6.1.5.5.7".
>
> The waste of ressources would be terribly reduced, because the standards themselves would be
> _not_ have to be rewritten if you want to do things in XML.
Although all you say is technically correct, the "truth" (dangerous stuff), is that writing ASN.1
and defining OIDs is something that is "hard to market" and will limit audience to a set of "gurus".
This would be bad if we anticipate end-user-community profiling of some magnitude. I do at least.
If our goal is to make PKI popular and useful, we should try to become compatible with the rest of the
"e-world" which is leaving EDI (in spite of being used for 20 years or so), and proprietary systems in favor of XML.
I.e. PKIX should not bother about ASN.1 <-> XML conversions except for firmly rooted things like
PKCs and CRLs. For new protocols and structures we should IMO *only* target XML.
But as there is no chance of reaching consensus on that (the EDI to XML "conversion process" is
likely to take 5-7 years or so to give you a hint of what we are dealing with), it may be easier to
move PKIX-like XML activities to a new WG? Poll Time?
Regards
Anders Rundgren
co-founder, X-OBI AB
+46 70 - 627 74 37
Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22210 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 11:06:33 -0800 (PST)
Received: from [45.50.1.25] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G4400LVMQKDNE@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 16 Nov 2000 10:12:13 -0800 (PST)
Date: Thu, 16 Nov 2000 10:13:18 -0800
From: Aram Perez <aram@pacbell.net>
Subject: Re: Should PKIX protocols support XML well?
In-reply-to: <3A1419B3.7F6C8CFE@certplus.com>
To: ietf-pkix <ietf-pkix@imc.org>
Message-id: <B63963BD.2809%aram@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022
I think we need to do a manual recount of the ASN.1 vs. XML votes... ;-)
My dos centavos,
Aram Perez
Received: from jlc.net (3ff83a80.dsl.flashcom.net [63.248.58.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17369 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 10:50:20 -0800 (PST)
Received: (from pkoning@localhost) by jlc.net (8.9.3/8.8.7) id NAA10807; Thu, 16 Nov 2000 13:57:41 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <14868.11813.731635.55034@pkoning.ironstream.com>
Date: Thu, 16 Nov 2000 13:57:41 -0500 (EST)
From: Paul Koning <pkoning@ironstream.com>
To: michael@stroeder.com
Cc: ietf-pkix@imc.org
Subject: Re: Should PKIX protocols support XML well?
References: <OF11437FCC.7FC0ACBB-ON85256999.00536274@iris.com> <3A1408F8.74DCDDE1@stroeder.com> <3A1419B3.7F6C8CFE@certplus.com> <3A14229D.E66C9559@stroeder.com>
X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA17379
>>>>> "michael" == michael <=?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>> writes:
michael> Jean-Marc Desperrier wrote:
>> Michael Ströder wrote:
>>
>> > With XML you can simply download e.g. a DTD from > the URL in
>> the XML data and use it to verify if the XML data is > compliant
>> to the schema.
>>
>> Michael, you don't seem to realize that it's very difficult for
>> many peoples to define an URL that is garanted to be persistent.
michael> This very valid observation applies to every URI you store
michael> in certificate extensions either.
Absolutely. It is important to realize that every URL in any stored
document was fairly likely to be valid around the time the document
was created -- and less and less likely to be valid the more time has
elapsed since then.
Therefore URLs should never be used as pointers to data that is
essential for the correct interpretation of the enclosing document.
They should only be used to point to data that is merely informative.
paul
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05493 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 10:14:03 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id C8E36683CC for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 19:08:29 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A14229D.E66C9559@stroeder.com>
Date: Thu, 16 Nov 2000 19:08:29 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well?
References: <OF11437FCC.7FC0ACBB-ON85256999.00536274@iris.com> <3A1408F8.74DCDDE1@stroeder.com> <3A1419B3.7F6C8CFE@certplus.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA05496
Jean-Marc Desperrier wrote:
>
> Michael Ströder wrote:
>
> > With XML you can simply download e.g. a DTD from
> > the URL in the XML data and use it to verify if the XML data is
> > compliant to the schema.
>
> Michael, you don't seem to realize that it's very difficult
> for many peoples to define an URL that is garanted to be persistent.
This very valid observation applies to every URI you store in
certificate extensions either.
Ciao, Michael.
Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04972 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 10:11:52 -0800 (PST)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <W6JXG6S7>; Thu, 16 Nov 2000 13:15:45 -0500
Message-ID: <A105E1C02F5DD31181A500508B5519EC519AE0@blue.identrus.com>
From: Khaja Ahmed <Khaja.Ahmed@identrus.com>
To: "'Anders Rundgren '" <anders.rundgren@telia.com>, "'Paul Koning '" <pkoning@ironstream.com>
Cc: "'kent@bbn.com '" <kent@bbn.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: Security with XML vs ASN.1. Was: Should PKIX protocols suppo rt XML well
Date: Thu, 16 Nov 2000 13:15:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04FF9.3CB83560"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C04FF9.3CB83560
Content-Type: text/plain;
charset="iso-8859-1"
Anders Rundgren wrote:
>I have been adviced to start a new WG to avoid further clashes or going
> for two solutions for every protocol. What do U think?
This would be an excellent thing. There is a lot of important work being
done outside of IETF which can now be done within IETF if this were to
happen. This would marry IETFs strengths in the arena of developing well
reviewed and robust standards with important market needs.
Khaja
------_=_NextPart_001_01C04FF9.3CB83560
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Security with XML vs ASN.1. Was: Should PKIX protocols =
support XML well</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Anders Rundgren wrote:</FONT>
<BR><FONT SIZE=3D2>>I have been adviced to start a new WG to avoid =
further clashes or going</FONT>
<BR><FONT SIZE=3D2>> for two solutions for every protocol. =
What do U think?</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>This would be an excellent thing. There is a =
lot of important work being done outside of IETF which can now be done =
within IETF if this were to happen. This would marry IETFs =
strengths in the arena of developing well reviewed and robust standards =
with important market needs.</FONT></P>
<P><FONT SIZE=3D2>Khaja</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C04FF9.3CB83560--
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24541 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 09:37:22 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id GAA22227; Fri, 17 Nov 2000 06:44:32 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97439668230894>; Fri, 17 Nov 2000 06:44:42 (NZDT)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: ambarish@valicert.com, ietf-pkix@imc.org, rsalz@caveosystems.com
Subject: RE: OCSP identifiers
Sender: pgut001@cs.auckland.ac.nz
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 17 Nov 2000 06:44:42 (NZDT)
Message-ID: <97439668230894@kahu.cs.auckland.ac.nz>
Ambarish Malpani <ambarish@valicert.com> writes:
>Our definition for CertID when from:
>
>(Serial#, IssuerPKHash)
>[which was my original suggestion]
>
>to
>
>(Serial#, IssuerPKHash, IssuerDN)
>[because of a comment that Steve Kent had made saying that
>responders might not index a CA's data based on its PKHash]
>
>to
>(Serial#, IssuerPKHash, IssuerDNHash)
>[because Mike Myers thought that the IssuerDN was too long to have
>in the querry - Mike, please correct me if I have the reason wrong]
I would really like to see this fixed, as I pointed out in my earlier message
you can do something with the issuer name and serial number (which as
issuerAndSerialNumber has been found perfectly adequate in the S/MIME world for
years), you can work with hash( iAndS ) (since it's trivial to convert iAndS
into the hashed form), but you can't do anything when one component is in a
hashed form and the other one isn't (well, unless your implementation happens
to use this mixture as a key). At the moment it's not possible for me to
create an OCSP responder because it doesn't provide any useful/standard way to
identify a cert.
Peter.
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20657 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 09:24:46 -0800 (PST)
Received: from certplus.com ([192.168.212.171]) by certplus.com (8.8.7/8.8.7) with ESMTP id SAA09092 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 18:36:22 +0100
Message-ID: <3A1419B3.7F6C8CFE@certplus.com>
Date: Thu, 16 Nov 2000 18:30:27 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well?
References: <OF11437FCC.7FC0ACBB-ON85256999.00536274@iris.com> <3A1408F8.74DCDDE1@stroeder.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Michael Ströder wrote:
> With XML you can simply download e.g. a DTD from
> the URL in the XML data and use it to verify if the XML data is
> compliant to the schema.
Michael, you don't seem to realize that it's very difficult for many peoples to
define an URL that is garanted to be persistent.
What do you do the day the compagny changes domain name, or decides to
reorganize it's html server tree ?
In the world I live in, this happens all the time and destroys thousands of
links without pity.
How does it miraculously never happen for XML when it happens all the time for
HTML ?
It won't just because it's so bad for XML ?
No one will be that stupid ? I don't bet on people's stupidity.
I believe the W3C can handle really persistent link, Netscape probably can too,
I not convinced Microsoft will prove to be able to, and many smaller player will
be completely unable to do it.
And when you use a local name instead of an URL, you become very collision prone
if it's not choosen carefully, wich is fully between the hands of the XML
document designer, wich will not be always so capable.
Therefore I'm _not_ convinced this system is such a great idea and something you
must so proud of.
This is very probably not the strongest point of XML.
In fact, in we were changing from ASN1 to XML, I'd suggest to use instead URI of
the form "oid:1.3.6.1.5.5.7" and have a level of indirection that is able to get
the document from it's oid when it's a public document or to have it stored
locally to solve security problems.
Something as simple as add the following string (user configurable) to the OID
to do an HTTP request, and if the HTTP server answers with a redirection, follow
it, repeat process as long you get a redirection instead of authoritative answer
might work.
It could even be https links, so if you are confident in the first server, you
are sure the end result will be also correct.
I have already received an XML document where I did not have access to the DTD.
I just couldn't even open it with the XML tool I had. It was very fun :-(.
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16795 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 09:11:40 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA27390 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 11:55:59 -0500 (EST)
Message-Id: <200011161655.LAA27372@roadblock.missi.ncsc.mil>
Date: Thu, 16 Nov 2000 12:11:27 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: Should PKIX protocols support XML well?
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=ISO-8859-1
Content-MD5: QcbKqFeeMx3ZwD4i6nAD3Q==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id JAA16798
> From: Michael Ströder <michael@stroeder.com>
>
> But in the case of an OID defining an ASN.1 syntax (widely used in
> PKIX) where can I automatically locate the syntax? You have to teach
> your application a-priori knowledge for simply verifiying the
> structure (not to mention all these more or less human-readable
> aliases for OIDs). With XML you can simply download e.g. a DTD from
> the URL in the XML data and use it to verify if the XML data is
> compliant to the schema.
With widely-used ASN.1 syntax the definition is expected to be stable
enough so that manually downloading an RFC from an FTP server and
importing a module into a library is considered adequate. The manual
process only needs to be done once; then the library of standard
modules is available to all users of a particular package. I assume
Jonah, Secude, OSS, OpenSSL, Cryptlib, and other packages all include
extensive ASN.1 libraries.
It hasn't been apparent that dynamically downloadable ASN.1 type
definitions are needed, and I'm not aware of a service that provides
them. However, it would be trivial for someone to set up such a server
containing ASN.1 definitions, and include the server URL in attribute
certificates. The application verifying an AC could query the server
for definitions of any attributes not defined in its local library,
e.g. http://asn1-server.org/q?oid=1.3.6.1.5.5.7.10.1 to retrieve the
definition for authenticationInfo.
As Anders points out, this is theory, not practice. But given the
triviality of putting it into practice, the current lack of
downloadable type definitions is not much of an argument against the
use of ASN.1 for attribute certificates. Should we define a PKIX
type-server attribute now, just to get the ball rolling?
id-aca-typeServer OBJECT IDENTIFIER ::= { id-aca 6 } -- IA5String URI
Received: from slack.lne.com ([209.157.136.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12874 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 08:58:29 -0800 (PST)
Received: (from ericm@localhost) by slack.lne.com (8.11.0/8.11.0) id eAGH5P105099; Thu, 16 Nov 2000 09:05:25 -0800
Date: Thu, 16 Nov 2000 09:05:25 -0800
From: Eric Murray <ericm@lne.com>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
Cc: PKIX-List <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well?
Message-ID: <20001116090525.M26204@slack.lne.com>
References: <OF11437FCC.7FC0ACBB-ON85256999.00536274@iris.com> <3A1408F8.74DCDDE1@stroeder.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.2i
In-Reply-To: <3A1408F8.74DCDDE1@stroeder.com>; from michael@stroeder.com on Thu, Nov 16, 2000 at 05:19:04PM +0100
On Thu, Nov 16, 2000 at 05:19:04PM +0100, Michael Ströder wrote:
>
> But in the case of an OID defining an ASN.1 syntax (widely used in
> PKIX) where can I automatically locate the syntax? You have to teach
> your application a-priori knowledge for simply verifiying the
> structure (not to mention all these more or less human-readable
> aliases for OIDs). With XML you can simply download e.g. a DTD from
> the URL in the XML data and use it to verify if the XML data is
> compliant to the schema.
That sounds like a security problem. An attacker could modify
the DTD that you download. So you need to either verify the
integrity of the DTD, or authenticate its source, or both.
With what?
If all your cert-processing is in XML and needs DTDs, you've painted
yourself into a corner. You would have no way of verifying the DTDs that
you need to verify the DTD. There is going to have to be some sort
of a priori knowledge of on-the-wire formats required by the end entities--
they can't get it all from somewhere else. No matter if you use XML
or ASN.1 or ad-hoc formats like SSL/TLS or SSH use.
Adding the download of the schema (after the EE's verfied it and the source)
adds another point of failure. Depending on the security model of
the system in question, this could be a problem.
On a different sub-issue of the ASN.1 vs. XML: ASN.1 has two purposes-
one is to, along with an encoding mechanisim like BER or DER, define the
on-the-wire protocol. The other is to provide a human-readable grammar
for describing the protocol, which is what's published into specs.
XML tries to do both at once, by making the on-the-wire protocol be the
human readable definition. I submit that it's harder to read than ASN.1
grammar is, especially older ASN.1.
If XML follows the evolution that HTML has followed in the past six
years, it will only get harder to read. A grammar that's hard to read
and understand results in specs with hidden flaws. Anything that's
proposed as a grammar for describing protocols in specs should address
the readability issue.
--
Eric Murray Consulting Security Architect SecureDesign LLC
http://www.securedesignllc.com PGP keyid:E03F65E5
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10204 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 08:48:10 -0800 (PST)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP for <ietf-pkix@imc.org> id 9832915531; Thu, 16 Nov 2000 11:55:16 -0500 (EST)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 550CB7C0E8 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 11:55:16 -0500 (EST)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <WMP2461D>; Thu, 16 Nov 2000 11:55:27 -0500
Message-ID: <AAD0807E1794D311A54000A0C99609B9165134@macertco-srv1.ma.certco.com>
From: "Tiernan, Tim" <tiernant@CertCo.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: unsubscribe
Date: Thu, 16 Nov 2000 11:55:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
unsubscribe
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08591 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 08:42:23 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA13730; Thu, 16 Nov 2000 17:55:49 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA11896; Thu, 16 Nov 2000 17:49:13 +0100
Message-ID: <3A14100C.48C9C8D0@bull.net>
Date: Thu, 16 Nov 2000 17:49:16 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <ambarish@valicert.com>
CC: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well
References: <613B3C619C9AD4118C4E00B0D03E7C3E153006@exchange.valicert.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ambarish,
> Hi Denis,
> No arguments with your statement that ASN.1 is more compact
> than XML.
:-)
So for long term storage, I would favor ASN.1.
> However, as applications start doing more and more with
> XML, they also invent mechanisms to store the XML in a way that they
> prefer to work with (for example, in our Receipt product line, we
> have a mechanism to store the XML in a relational database). Once
> people have done this, they would prefer to have XML as their data
> format for everything, rather than storing a base64 blob of ASN.1
> in their database that they need to write special code to view.
The point I made was specific to the storage of some signed data, like a
certificate, a CRL or an OCSP response. No other type of data.
> The basic observation is that applications normally have a preferred
> format for data.
Many applications usually prefer C ++, because it is what they are made
from. (C ++ is only an example - please, no war with C or ADA)
> If an application is doing everything in XML, that
> is likely to be their prefered format and they are likely to want
> their certificate validation protocol to be in that format, rather
> than another one.
I could argue the same for ASN.1, but this is NOT the point. Let us use an
example:
At the time an XML application receives an OCSP response, it "sees" it in
C ++ (because it is translated from ASN1 into C ++ data structures).
At the time an XML application would like to see again the content of an
OCSP response (which was in ASN.1), it could send the blob to a local
application (originally developped in ASN.1) which will respond by sending
an ASN.1 copy of the blob, ... magically translated into C ++. As an end
result XML applications and XML programmers only see C ++. :-)
Instead of asking the server to provide two sets of responses (i.e. one in
ASN.1 and one in XML), a single response could be provided (ASN.1).
[I already hear people saying XML, but remember the first argument, XML is
far less compact]. This response could be translated, NOT into XML, but
into the programming language being used (e.g. C or C ++).
So the request would contain the ASN.1 blob, while the response would be in
C ++. Quite a simple service. This approach could be generalized for
certificates (both public key certificates and attribute certificates), CRLs
and OCSP responses, as well as for new signed data structures.
The next question is how to verify years later such a structure. Well, this
may be quite complex and subcontracting the work to a server would be wise.
Light clients would use some new protocols, they could be in ASN.1 for
compactness, since anyway, what remains visible is the programming langage.
Is it a crazy idea ?
Denis
Note: I am not an ASN.1 compiler vendor. :-)
> Regards,
> Ambarish
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect 650.567.5457
> ValiCert, Inc. ambarish@valicert.com
> 339 N. Bernardo Ave. http://www.valicert.com
> Mountain View, CA 94043
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > Sent: Tuesday, November 14, 2000 6:27 AM
> > To: Ambarish Malpani
> > Cc: 'ietf-pkix@imc.org '
> > Subject: Re: Should PKIX protocols support XML well
> >
> >
> > Ambarish,
> >
> > > Hi Steve/Russ,
> > > I hope nothing that I posted even implied that I recommend that
> > > certs and CRLs be encoded in XML. I think there is enough investment
> > > in ASN.1 certs/CRLs etc. to not make it a worthwhile effort. The
> > > remark I was trying to make is that I think future PKIX work should
> > > try and see if specifying protocols in XML or both XML and ASN.1
> > > make sense for the task they are trying to do.
> > >
> > > This is precisely why I tried to specify SCVP in both syntaxes.
> >
> > Let me jump into this discussion. ASN.1 has been used
> > historically to define
> > *protocols*. Since such protocols were carrying data
> > structures that could
> > have their own existence outside their transmission in the
> > protocols, we
> > ended up with ASN.1 for *data structures*. The prime examples are
> > certificates and CRLs.
> >
> > The basic question is thus NOT whether we should specify new
> > protocols in
> > ASN.1, XML or both XML and ASN.1, but rather whether we want
> > to define NEW
> > data structures in XML or ASN.1. As an example, an OCSP
> > response is an ASN.1
> > data structure that has an existence beyond its transmission in the
> > protocol, since it can be stored and re-used to make sure,
> > e.g., it was
> > correctly signed.
> >
> > The basic question is thus the following : should new data structures,
> > signed by an authority, which would vouch for the validity
> > (they are various
> > flavors around that term) of a certificate or certificate
> > chain against some
> > rules be defined in ASN.1 and/or XML ?
> >
> > Let me just provide one first argument: ASN.1 is much more
> > compact than XML.
> > There are other arguments indeed. You are welcome to provide them.
> >
> > Denis
> >
> > > Regards,
> > > Ambarish
> > >
> > >
> > ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Architect
> > 650.567.5457
> > > ValiCert, Inc.
> > ambarish@valicert.com
> > > 339 N. Bernardo Ave.
> > http://www.valicert.com
> > > Mountain View, CA 94043
> > >
> > > > -----Original Message-----
> > > > From: Stephen Kent [mailto:kent@bbn.com]
> > > > Sent: Monday, November 13, 2000 11:04 AM
> > > > To: Ambarish Malpani
> > > > Cc: 'ietf-pkix@imc.org '
> > > > Subject: Re: Should PKIX protocols support XML well
> > > >
> > > >
> > > > Ambarish,
> > > >
> > > > XML has various benefits for representing certain kinds
> > of data, but
> > > > none of those seem especially relevant to the encoding of certs or
> > > > CRLs. Moreover, at a time when people in various quarters (e.g.,
> > > > wireless folks) complain about the size of certs, it
> > would not seem
> > > > especially appropriate to adopt an XML encoding, which
> > would increase
> > > > the size of these data items.
> > > >
> > > > I am not persuaded by comments that allude only to the
> > "trendiness"
> > > > of XML vs. ASN.1 encoding, as several others have pointed
> > out. PKIX
> > > > was started as a profiler of X.509 protocols, and we have expanded
> > > > our charter to create new protocols that support X.509 certs and
> > > > which seem appropriate to PKI use in the Internet. That
> > makes it hard
> > > > to justify developing new syntax for existing data structures, as
> > > > noted above. However, as Russ pointed out, standards for
> > carriage of
> > > > certs and CRLs (ASN.1 encoded) in an XML context are not
> > out of the
> > > > question.
> > > >
> > > > Steve
> > > >
> > >
> > > ----------------Russ's Original Message-------------
> > > Ambarish:
> > >
> > > I agree that we need to support XML clients. It would not
> > have been one of
> > > my three criteria if I thought otherwise. However, I do
> > not think that we
> > > should abandon ASN.1. I think that certificates and CRLs
> > MUST be ASN.1
> > > encoded. Providing an XML wrapper to carry an
> > ASN.1-encoded blob is just
> > > fine. Base64-encode it if you like. Anyway, the server
> > can obtain the
> > > ASN.1-encode certificate perform validation services. The
> > server will
> > > return an indication of validity and parse some information
> > (especially the
> > > public key, alt names, and critical extension information) from the
> > > certificate. This will allow the client to be completely
> > ASN.1 ignorant.
> > >
> > > I realize that this is just one aspect of making the entire
> > system XML
> > > client friendly; however, I think that it is a very
> > reasonable place to
> > > begin. In many systems, enrollment is handled by issuing a
> > token (such as
> > > a smart card). In this case, the client has nothing to do with
> > > enrollment. So, certificate validation is a good place to begin.
> > >
> > > Russ
> > > -------------End of Message----------------------------
> >
Received: from [206.117.68.68] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07526 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 08:38:55 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0501046ab639beb5f8d1@[206.117.68.68]>
In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F401C5B5A3@vhqpostal.verisign.com>
References: <2F3EC696EAEED311BB2D009027C3F4F401C5B5A3@vhqpostal.verisign.com>
Date: Thu, 16 Nov 2000 08:46:26 -0800
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: RE: DPV vs SCVP
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 10:08 AM -0800 11/15/00, Michael Myers wrote:
>Replace "good" with "not revoked"
>---------------------------------
>The last call for comments on the I-D that led to RFC2560 occurred roughly
>two years ago.
>
>
>Replace "unknown" with "revocation status unknown"
>--------------------------------------------------
>See above.
OCSPv2 is a new protocol, which means that bugs in the old protocol
can be fixed. I'm not saying that I agree with Denis' requests, but
it is inappropriate to give an out of hand rejection to them simply
because they had been discussed before, at the same time as the othe
flaws in OCSP were being considered.
If the author of a document is not willing to work within the IETF
framework, maybe it is time for a different author or additional
co-authors, such as the ones who helped craft OCSPv1.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04568 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 08:26:40 -0800 (PST)
Received: from certplus.com ([192.168.212.171]) by certplus.com (8.8.7/8.8.7) with ESMTP id RAA08103 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 17:39:00 +0100
Message-ID: <3A140C40.82624DD2@certplus.com>
Date: Thu, 16 Nov 2000 17:33:04 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well
References: <613B3C619C9AD4118C4E00B0D03E7C3E153006@exchange.valicert.com> <029701c04fe3$646401a0$0201a8c0@vincent.se>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Anders Rundgren wrote:
> > The basic observation is that applications normally have a preferred
> > format for data. If an application is doing everything in XML, that
> > is likely to be their prefered format and they are likely to want
> > their certificate validation protocol to be in that format, rather
> > than another one.
>
> This is absolutely correct. So what do we do now to create this exciting new
> XML-based PKI stuff? Create a new WG? Any suggestions?
>
> I personally do *not* believe Ãn creating dual track standards, as that would be a terrible
> wast of talent and resources.
It has been proposed that a XER (XML encoding rule) be defined.
In fact I think it's even feasible to write a standard that can converts an ASN.1 definition,
with incorporated constraints, to an equivalent DTD and schema.
Together with a normalised XML representation, a document created using this DTD and schema
would be the XER representation of the ASN.1, and could be created using standard XML tools
that understands DTD/schema.
We can have a convertion rule from OIDs to URI : for example as simple as "oid:1.3.6.1.5.5.7".
The waste of ressources would be terribly reduced, because the standards themselves would be
_not_ have to be rewritten if you want to do things in XML.
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01668 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 08:14:45 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 07159683CA for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 17:19:05 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A1408F8.74DCDDE1@stroeder.com>
Date: Thu, 16 Nov 2000 17:19:04 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: PKIX-List <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well?
References: <OF11437FCC.7FC0ACBB-ON85256999.00536274@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
John_Wray@iris.com wrote:
>
> OIDs are allocated in a hierarchichal, distributed fashion that guarantees
> universal uniqueness.
Yes, I know.
> There is no requirement that there be any ASN.1 definition "related to" a
> given OID. Many (most?) OIDs identify things other than syntaxes (for
> example, many OIDs identify cryptographic algorithms).
Yes, I know.
But in the case of an OID defining an ASN.1 syntax (widely used in
PKIX) where can I automatically locate the syntax? You have to teach
your application a-priori knowledge for simply verifiying the
structure (not to mention all these more or less human-readable
aliases for OIDs). With XML you can simply download e.g. a DTD from
the URL in the XML data and use it to verify if the XML data is
compliant to the schema.
Ciao, Michael.
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21008 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 07:46:02 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4400G01K5DU8@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 16 Nov 2000 07:53:37 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4400G7YK5C14@ext-mail.valicert.com>; Thu, 16 Nov 2000 07:53:36 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NLYKC>; Thu, 16 Nov 2000 07:51:33 -0800
Content-return: allowed
Date: Thu, 16 Nov 2000 07:51:32 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: OCSP identifiers
To: "'Rich Salz'" <rsalz@caveosystems.com>, ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E153008@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Hi Rich,
Our definition for CertID when from:
(Serial#, IssuerPKHash)
[which was my original suggestion]
to
(Serial#, IssuerPKHash, IssuerDN)
[because of a comment that Steve Kent had made saying that
responders might not index a CA's data based on its PKHash]
to
(Serial#, IssuerPKHash, IssuerDNHash)
[because Mike Myers thought that the IssuerDN was too long to have
in the querry - Mike, please correct me if I have the reason wrong]
The question before us now is: Even though we might not be delighted
with the current definition of CertID, should we change it or continue
on with the current definition.
My argument in the past for inclusion of either the Issuer's public key
or the hash of the Issuer's public key is that I don't believe that we
have any way of guaranteeing uniqueness of DNs. If a OCSP client doesn't
send the whole certificate to the OCSP Responder, the responder has no
way of guaranteeing that the Issuer that the client thinks issued the
certificate is the same one as the one that the responder is responding
for.
Having the client send over the issuer's public key in some way helps us
avoid even the possibility of this problem and if we assume that the client
is checking the signature on the cert, then having it send over the hash
of the issuer's public key isn't placing too stiff a requirement on it.
Hope this helps clarify both the history and the reasoning behind what
happenned with CertIDs.
Again, the question is, should we continue with the current definition or
change it and if so, how.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Rich Salz [mailto:rsalz@caveosystems.com]
> Sent: Wednesday, November 15, 2000 5:45 PM
> To: ietf-pkix@imc.org
> Subject: OCSP identifiers
>
>
> Be careful of sending the entire cert in a status or validity
> query. At a
> previous employer it became pretty clear (with a patent
> attorney) that this
> violated a patent held by Micali. No, I don't remember the
> number. But it was
> a good thing that the OCSP syntax changed from the -02 draft. :)
>
> As for what identifiers to use, I always thought that
> requiring the issuer's
> cert was onerous, and that sending the hash "for space
> reasons" was a bogus
> argument. I further agree with Gutmann that it required weird
> indices on the
> part of many implementors.
>
> I always thought {Issuer-DN, Subject-DN, Serial#} was
> relatively short and to
> the point and unique.
> /r$
>
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16675 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 07:33:55 -0800 (PST)
Received: from asn-1.com (user-2ivf6l0.dialup.mindspring.com [165.247.154.160]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id HAA11395 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 07:45:29 -0500 (EST)
Message-ID: <3A13D680.FE6B5548@asn-1.com>
Date: Thu, 16 Nov 2000 07:43:44 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: OCSP-X vs SCVP
References: <613B3C619C9AD4118C4E00B0D03E7C3E136631@exchange.valicert.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Frank Balluffi wrote:
>
> Phil,
>
> It might be useful to be able to control the level of "opaqueness". For
> example, a certification path validation protocol might want to include XML
> extensions in its requests and responses, but treat certificates, CRLs and
> OCSP responses (which may also include extensions) as "opaque" DER-encoded
> elements.
>
> Frank
Frank,
There are many approaches that can be taken. I seek to
create a general purpose capability, one that allows
XML to be used on both ends of the line with efficient
encoded binary in between; one that allows end to end
text in a canonical form; one that allows an XML only
client to communicate through a firewall to a server
that can process requests and responses in either text
or binary; one that allows developers to display all
ASN.1 values using markup when debugging.
But this approach will surely not solve all problems.
I imagine that often it will be useful to include XML
payloads in ASN.1 encodings. Extension and attribute
XML payloads surely. And consider the following:
Response ::= SEQUENCE {
rc INTEGER,
msg OCTET STRING (CONTAINING UTF8String
ENCODED BY xml)
}
This constraint reveals the structure in an octet
hole as containing unicode and the xml OID can be
used to signal further processing of the value in
the opaque string. Of course, a parser or coder
tool can simply choose to ignore the constraint
as well, and treat msg as a simple opaque string.
When this piece of XML needs to be protected, there
are no white space or line feed considerations on
either end of the line. The markup can simply be
treated as an opaque value until it needs to be
displayed or further processed as an XML entity.
Phil
>
> > -----Original Message-----
> > From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com]
> > Sent: Sunday, November 12, 2000 12:46 AM
> > To: rsalz@CaveoSystems.com
> > Cc: ietf-pkix@imc.org
> > Subject: Re: OCSP-X vs SCVP
> >
> >
> >
> > >
> > > Certainly ASN.1 is older and parts are more stable, but
> > it's also growing
> > > (and has grown -- PKIX1Explicit88, e.g.). So is XMLSchema. For the
> > > purposes of comparison, let's just call them equivalent.
> >
> > But they are not. And you misunderstand. The module
> > PKIX1Explicit88 is not itself ASN.1. It is one module
> > of one specification written using ASN.1. It is a
> > collection of definitions based on ASN.1 types. The
> > values of these types conform to both the structure
> > and rules for values defined by the ASN.1 standards.
> >
> > >
> > > >If there were but one XML schema life would
> > > >be easy. But there are many XML schema, and
> > > >more seem to be popping up in various XML
> > > >communities.
> > >
> > > That makes no more sense than saying there should be but
> > one ASN.1 module.
> >
> > No. An ASN.1 module is not a schema.
> >
> > But ASN.1 can provide a schema for markup values
> > that are associated with ASN.1 type definitions.
> > This association makes it possible for ASN.1
> > applications to transfer values to and from XML
> > applications in a standard way. So ASN.1 can be
> > used to define another set of rules, like BizTalk,
> > DT4-DTD or XML-schema, for what constitutes valid
> > typed values. Markup is just another way to
> > represent these values.
> >
> > >
> > > I'm not advocating that the IETF, the Security Area or the
> > PKIX WG "use"
> > > XML (for some definition of use). I am trying to show that the XML
> > > communities are working to define *everything* needed to
> > describe and
> > > exchange data. It might not make sense to use it -- I personally
> > > see little point in rewriting X.509v3 datatypes in XML-Schema -- but
> > > we should be aware of what's going on for if/when we do
> > decide to work
> > > in that space.
> > > /r$
> >
> > Agreed. What I am proposing is to modify the ASN.1
> > standards so that the values of all ASN.1 types can
> > be expressed using a common XML markup.
> >
> > So that for an arbitrary type definition, say
> >
> > MyType ::= SEQUENCE {
> > label PrintableString,
> > value INTEGER
> > }
> >
> > a value of that type can be decoded by a recipient (or
> > encoded and transferred by a sender) using the markup
> >
> > <MyType>
> > <label>
> > </label>
> > <value>
> > </value>
> > </MyType>
> >
> > And so that a valid value of that ASN.1 type, a value
> > which conforms to the rules defined in the ASN.1
> > standards, such as
> >
> > userValue MyType ::= {
> > label "My shoe size is ",
> > value 10
> > }
> >
> > can be encoded and transferred as either ASN.1
> > encoded binary data or as the markup value
> >
> > <MyType>
> > <label>
> > My shoe size is
> > </label>
> > <value>
> > 10
> > </value>
> > </MyType>
> >
> > This will provide a means to extend the capability
> > deployed today - the ability to unambiguously encode
> > and decode a value of an ASN.1 type. A standard markup
> > for the ASN.1 notation will provide a new format for
> > expressing the same ASN.1 values.
> >
> > By binding a standard markup to the values defined as
> > valid for ASN.1 types, it will be possible for an ASN.1
> > application to send or receive ASN.1 values in either
> > text or binary formats.
> >
> > Phil
> > ----
> > Phillip H. Griffin Griffin Consulting
> > http://asn-1.com Secure ASN.1 Design & Implementation
> > +1-919-832-7008 1625 Glenwood Avenue, Five Points
> > +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA
> > ------------------------------------------------------------
> >
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16335 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 07:33:15 -0800 (PST)
Received: from mega (t5o69p50.telia.com [213.64.110.50]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id QAA04125; Thu, 16 Nov 2000 16:40:45 +0100 (CET)
Message-ID: <029701c04fe3$646401a0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Ambarish Malpani" <ambarish@valicert.com>, "'Denis Pinkas'" <Denis.Pinkas@bull.net>
Cc: <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E153006@exchange.valicert.com>
Subject: Re: Should PKIX protocols support XML well
Date: Thu, 16 Nov 2000 16:39:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA16342
Ambarish,
> Hi Denis,
> No arguments with your statement that ASN.1 is more compact
> than XML. However, as applications start doing more and more with
> XML, they also invent mechanisms to store the XML in a way that they
> prefer to work with (for example, in our Receipt product line, we
> have a mechanism to store the XML in a relational database). Once
> people have done this, they would prefer to have XML as their data
> format for everything, rather than storing a base64 blob of ASN.1
> in their database that they need to write special code to view.
>
> The basic observation is that applications normally have a preferred
> format for data. If an application is doing everything in XML, that
> is likely to be their prefered format and they are likely to want
> their certificate validation protocol to be in that format, rather
> than another one.
This is absolutely correct. So what do we do now to create this exciting new
XML-based PKI stuff? Create a new WG? Any suggestions?
I personally do *not* believe Ãn creating dual track standards, as that would be a terrible
wast of talent and resources.
Anders
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15234 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 07:30:27 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA14476; Thu, 16 Nov 2000 16:43:58 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA24210; Thu, 16 Nov 2000 16:37:13 +0100
Message-ID: <3A13FF2C.6BD87C5B@bull.net>
Date: Thu, 16 Nov 2000 16:37:16 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Rich Salz <rsalz@caveosystems.com>, Michael Myers <MMyers@verisign.com>
CC: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <3A133C35.81D9649C@caveosystems.com> <3A13B373.B4DA2D0D@bull.net> <3A13E1DE.780F8D07@caveosystems.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA15252
Rich, Simon and Mike,
This is a response to you and Simon (Tardell), but also a message for Mike.
> > Not always unique. :-(
> >
> > .. in case of an issuing key compromise.
>
> So what kind of identifier *is* unique in the case of issuer compromise?
> The hash of the (subject) cert,
No exactly. More precisely : CA name + issuerKeyHash + certicate serial
number + certhash
> provided your query is about a time *before* the compromise, of course.
This sentence raises an important point. This case may happen, in
particular, if the server is providing information beyond the expiry of the
certificate. In such case (see section 4.4.4 Archive Cutoff) it would be
rather dangerous to use a response, unless the hash of the cert is also
used. But this case would apply, in general, as soon as an issuing key is
compromised.
The server would have to choose between two options:
1° use the certhash, so that certhash comparisons can be done. This means
that the OCSP server would have to know the hash of every certificate. This
precludes to have this service CRL-based, since CRLs do not contain the hash
of each certificate; or
2° do not use certhash, and apply a fall back solution (similar to, but
different from, the one described in section 2.7): "An OCSP responder MUST
know that a particular CA's private key has been compromised. In such a
case, it MUST return the "revocation status unknown" state for all
certificates issued by that CA."
Some text additions both in the main sections and the security consideration
section would be appropriate.
> Gee, it sure would be convenient if I could ask
> about a cert, the issuer, and so on all the way up the chain with a single
> query. Anyone given thought to doing that? :)
>
> Sorry, bad joke.
:-)
It is half a joke.
All the chain up, the hash of each CA certificate would be to be considered
as well. However, starting a thread on that topic, would be, for the time
being, too time consuming for me, so I will not elaborate more.
Denis
> /r$
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12046 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 07:22:43 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4400G01J2CPM@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 16 Nov 2000 07:30:13 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4400FBYJ2CXB@ext-mail.valicert.com>; Thu, 16 Nov 2000 07:30:12 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NLYHK>; Thu, 16 Nov 2000 07:28:08 -0800
Content-return: allowed
Date: Thu, 16 Nov 2000 07:28:07 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: Should PKIX protocols support XML well
To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E153006@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Hi Denis,
No arguments with your statement that ASN.1 is more compact
than XML. However, as applications start doing more and more with
XML, they also invent mechanisms to store the XML in a way that they
prefer to work with (for example, in our Receipt product line, we
have a mechanism to store the XML in a relational database). Once
people have done this, they would prefer to have XML as their data
format for everything, rather than storing a base64 blob of ASN.1
in their database that they need to write special code to view.
The basic observation is that applications normally have a preferred
format for data. If an application is doing everything in XML, that
is likely to be their prefered format and they are likely to want
their certificate validation protocol to be in that format, rather
than another one.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Tuesday, November 14, 2000 6:27 AM
> To: Ambarish Malpani
> Cc: 'ietf-pkix@imc.org '
> Subject: Re: Should PKIX protocols support XML well
>
>
> Ambarish,
>
> > Hi Steve/Russ,
> > I hope nothing that I posted even implied that I recommend that
> > certs and CRLs be encoded in XML. I think there is enough investment
> > in ASN.1 certs/CRLs etc. to not make it a worthwhile effort. The
> > remark I was trying to make is that I think future PKIX work should
> > try and see if specifying protocols in XML or both XML and ASN.1
> > make sense for the task they are trying to do.
> >
> > This is precisely why I tried to specify SCVP in both syntaxes.
>
> Let me jump into this discussion. ASN.1 has been used
> historically to define
> *protocols*. Since such protocols were carrying data
> structures that could
> have their own existence outside their transmission in the
> protocols, we
> ended up with ASN.1 for *data structures*. The prime examples are
> certificates and CRLs.
>
> The basic question is thus NOT whether we should specify new
> protocols in
> ASN.1, XML or both XML and ASN.1, but rather whether we want
> to define NEW
> data structures in XML or ASN.1. As an example, an OCSP
> response is an ASN.1
> data structure that has an existence beyond its transmission in the
> protocol, since it can be stored and re-used to make sure,
> e.g., it was
> correctly signed.
>
> The basic question is thus the following : should new data structures,
> signed by an authority, which would vouch for the validity
> (they are various
> flavors around that term) of a certificate or certificate
> chain against some
> rules be defined in ASN.1 and/or XML ?
>
> Let me just provide one first argument: ASN.1 is much more
> compact than XML.
> There are other arguments indeed. You are welcome to provide them.
>
> Denis
>
> > Regards,
> > Ambarish
> >
> >
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect
> 650.567.5457
> > ValiCert, Inc.
> ambarish@valicert.com
> > 339 N. Bernardo Ave.
> http://www.valicert.com
> > Mountain View, CA 94043
> >
> > > -----Original Message-----
> > > From: Stephen Kent [mailto:kent@bbn.com]
> > > Sent: Monday, November 13, 2000 11:04 AM
> > > To: Ambarish Malpani
> > > Cc: 'ietf-pkix@imc.org '
> > > Subject: Re: Should PKIX protocols support XML well
> > >
> > >
> > > Ambarish,
> > >
> > > XML has various benefits for representing certain kinds
> of data, but
> > > none of those seem especially relevant to the encoding of certs or
> > > CRLs. Moreover, at a time when people in various quarters (e.g.,
> > > wireless folks) complain about the size of certs, it
> would not seem
> > > especially appropriate to adopt an XML encoding, which
> would increase
> > > the size of these data items.
> > >
> > > I am not persuaded by comments that allude only to the
> "trendiness"
> > > of XML vs. ASN.1 encoding, as several others have pointed
> out. PKIX
> > > was started as a profiler of X.509 protocols, and we have expanded
> > > our charter to create new protocols that support X.509 certs and
> > > which seem appropriate to PKI use in the Internet. That
> makes it hard
> > > to justify developing new syntax for existing data structures, as
> > > noted above. However, as Russ pointed out, standards for
> carriage of
> > > certs and CRLs (ASN.1 encoded) in an XML context are not
> out of the
> > > question.
> > >
> > > Steve
> > >
> >
> > ----------------Russ's Original Message-------------
> > Ambarish:
> >
> > I agree that we need to support XML clients. It would not
> have been one of
> > my three criteria if I thought otherwise. However, I do
> not think that we
> > should abandon ASN.1. I think that certificates and CRLs
> MUST be ASN.1
> > encoded. Providing an XML wrapper to carry an
> ASN.1-encoded blob is just
> > fine. Base64-encode it if you like. Anyway, the server
> can obtain the
> > ASN.1-encode certificate perform validation services. The
> server will
> > return an indication of validity and parse some information
> (especially the
> > public key, alt names, and critical extension information) from the
> > certificate. This will allow the client to be completely
> ASN.1 ignorant.
> >
> > I realize that this is just one aspect of making the entire
> system XML
> > client friendly; however, I think that it is a very
> reasonable place to
> > begin. In many systems, enrollment is handled by issuing a
> token (such as
> > a smart card). In this case, the client has nothing to do with
> > enrollment. So, certificate validation is a good place to begin.
> >
> > Russ
> > -------------End of Message----------------------------
>
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07665 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 07:11:04 -0800 (PST)
Received: from mega (t7o69p210.telia.com [213.65.46.210]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id QAA16276; Thu, 16 Nov 2000 16:18:34 +0100 (CET)
Message-ID: <027301c04fe0$4b2553e0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Paul Koning" <pkoning@ironstream.com>
Cc: <kent@bbn.com>, <ietf-pkix@imc.org>
Subject: Re: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
Date: Thu, 16 Nov 2000 16:17:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA07671
> Anders> The app-developer community (not PKIX) defines in (an
> Anders> hopefully) collaborative way *exactly* what their particular
> Anders> app needs so I really don't understand the question.
>
> Ok, if the app developer community, as opposed to the standards
> community, does these tweaks, how is that different from the app
> developer community taking an ASN.1 definition and tweaking it to
> their needs?
We can probably go on forever, but using app-schemas you would not "tweak"
anything as there is nothing to tweak. You design an app-unique schema.
ASN.1 has no *defined* schema mechanism.
Paul, apparently ASN.1-gurus feels that they have a superior solution and
the XML-zelots as well. The XML-zelots have (at least) the market on their side.
I have been adviced to start a new WG to avoid further clashes or going for
two solutions for every protocol. What do U think?
Anders
Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07441 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 07:10:37 -0800 (PST)
From: John_Wray@iris.com
Subject: Re: Should PKIX protocols support XML well?
To: Michael =?iso-8859-1?q?Str=F6der?= <michael@stroeder.com>
Cc: PKIX-List <ietf-pkix@imc.org>
X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000
Message-ID: <OF11437FCC.7FC0ACBB-ON85256999.00536274@iris.com>
Date: Thu, 16 Nov 2000 10:18:44 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/16/2000 10:18:14 AM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA07461
Michael,
OIDs are allocated in a hierarchichal, distributed fashion that guarantees
universal uniqueness.
There is no requirement that there be any ASN.1 definition "related to" a
given OID. Many (most?) OIDs identify things other than syntaxes (for
example, many OIDs identify cryptographic algorithms).
John
-----------
Michael Ströder <michael@stroeder.com>@ms.inka.de on 11/16/2000 05:09:36 AM
Sent by: michael@ms.inka.de
To: PKIX-List <ietf-pkix@imc.org>
cc:
Subject: Re: Should PKIX protocols support XML well?
Ed Gerck wrote:
>
> ASN.1 and OIDs are based on hierarchical design rules, central control.
XML is
> based on local control.
Ed, OIDs are subject of local control either.
If you disagree please show me the mechanism how my application can
locate and download the machine-readable ASN.1 definition related to
an arbitrary OID.
Ciao, Michael.
Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02556 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 06:56:55 -0800 (PST)
From: John_Wray@iris.com
Subject: Re: Should PKIX protocols support XML well?
To: "Anders Rundgren" <anders.rundgren@telia.com>
Cc: "Ed Gerck" <egerck@nma.com>, "PKIX-List" <ietf-pkix@imc.org>, "David P. Kemp" <dpkemp@missi.ncsc.mil>
X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000
Message-ID: <OFA671BA9F.164512CD-ON85256999.0051FBD3@iris.com>
Date: Thu, 16 Nov 2000 10:05:02 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/16/2000 10:04:33 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Anders,
>OIDs are inherently less flexible. And need "educated"
>parsers.
>
>An example: W2K CryptoAPI returns "OID.2.5.4.5=xyz"
>instead of "SerialNumber=xyz" so at
>least MSFT has some "education" left to do...
I don't understand how you're measuring flexibility, but I disagree with
your comment about educated parsers.
It would be an extremely well-educated parser that could work out for
itself what to do with the ASCII string "SerialNumber". I don't see why
such an intelligent piece of code should have any more trouble with the
three-byte OID value 2.5.4.5.
Or do you mean "human" (or more specifically "English-speaking human") when
you say "parser"? If so, then yes, XML has a definite advantage if you
intend it to be consumed by humans. But code doesn't understand ASCII (or
Unicode) any better than it understands hexadecimal values.
John
"Anders Rundgren" <anders.rundgren@telia.com> on 11/16/2000 06:49:09 AM
To: "Ed Gerck" <egerck@nma.com>
cc: "PKIX-List" <ietf-pkix@imc.org>, "David P. Kemp"
<dpkemp@missi.ncsc.mil>
Subject: Re: Should PKIX protocols support XML well?
Ed,
> but one point seem to be missed.
> ASN.1 and OIDs are based on hierarchical design rules, central control.
XML is
> based on local control. Both control paradigms are useful but, in many
cases,
> central control beats local control hands down in terms of security.
XML schemas stored and maintained on a secure server run by a trusted party
offers
the possibility to have central control. Which makes sense for *some*
apps.
OIDs are inherently less flexible. And need "educated" parsers.
An example: W2K CryptoAPI returns "OID.2.5.4.5=xyz" instead of
"SerialNumber=xyz" so at
least MSFT has some "education" left to do...
Anders
Received: from jlc.net (3ff83a80.dsl.flashcom.net [63.248.58.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27880 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 06:40:25 -0800 (PST)
Received: (from pkoning@localhost) by jlc.net (8.9.3/8.8.7) id JAA09654; Thu, 16 Nov 2000 09:47:58 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14867.62366.252251.866493@pkoning.ironstream.com>
Date: Thu, 16 Nov 2000 09:47:58 -0500 (EST)
From: Paul Koning <pkoning@ironstream.com>
To: phil.griffin@asn-1.com
Cc: ietf-pkix@imc.org
Subject: Re: Should PKIX protocols support XML well?
References: <97431154424428@kahu.cs.auckland.ac.nz> <3A13CB26.6563D3E4@asn-1.com>
X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid
>>>>> "Phillip" == Phillip H Griffin <phil.griffin@asn-1.com> writes:
Phillip> Peter Gutmann wrote (in part):
>> John_Wray@iris.com writes (partially):
>>
Phillip> snip
>> >The Jonah ASN.1 library doesn't do much checking of restrictions,
>> but that was >an implementation choice rather than something
>> imposed upon us by ASN.1.
>>
>> Doing strict checking is a downside, not a feature. In my code I
>> originally did strict checking for compliance to RFC 2459, but
>> found that there were so many certs which fail the checks that I
>> probably spent more time adding special-case code to handle
>> exceptions than in writing the cert-parsing code (I
Phillip> Certainly the only sane approach to decoding. And not
Phillip> getting hung up on enforcing DER restrictions on BER is a
Phillip> good idea, too.
Absolutely. This is the classic rule "be strict in what you send,
lenient in what you receive."
If the meaning of a received message is clear, pedantically enforcing
encoding rules is only harmful. It reduces interoperability and it
consumes resources to no benefit.
(Hm, do I sound like a Florida lawyer here? :-) )
paul
Received: from jlc.net (3ff83a80.dsl.flashcom.net [63.248.58.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26788 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 06:36:02 -0800 (PST)
Received: (from pkoning@localhost) by jlc.net (8.9.3/8.8.7) id JAA09648; Thu, 16 Nov 2000 09:43:35 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14867.62103.644827.870190@pkoning.ironstream.com>
Date: Thu, 16 Nov 2000 09:43:35 -0500 (EST)
From: Paul Koning <pkoning@ironstream.com>
To: anders.rundgren@telia.com
Cc: kent@bbn.com, ietf-pkix@imc.org
Subject: Re: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid
>>>>> "Anders" == Anders Rundgren <anders.rundgren@telia.com> writes:
>> If the schema is already defined before you discover the need to
>> implement the restriction, don't you have the same problem?
Anders> The app-developer community (not PKIX) defines in (an
Anders> hopefully) collaborative way *exactly* what their particular
Anders> app needs so I really don't understand the question.
Ok, if the app developer community, as opposed to the standards
community, does these tweaks, how is that different from the app
developer community taking an ASN.1 definition and tweaking it to
their needs?
Both have this flexibility. It doesn't make sense to argue that XML
is superior by assuming people will use that flexibility only with XML
and avoid using it with ASN.1.
paul
Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23443 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 06:22:33 -0800 (PST)
From: John_Wray@iris.com
Subject: Re: Should PKIX protocols support XML well?
To: Michael =?iso-8859-1?q?Str=F6der?= <michael@stroeder.com>
Cc: ietf-pkix@imc.org
X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000
Message-ID: <OF4CF8B4C0.D988709A-ON85256999.004DEC6A@iris.com>
Date: Thu, 16 Nov 2000 09:30:39 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/16/2000 09:30:10 AM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA23454
Michael,
>John, Peter, how does your code recognize any PKI-related object?
>IMHO you're doing some kind of type probing, don't you?
I can't speak for Peter's code, but the Jonah library allows you to define
objects that can parse and generate BER/DER according to a given ASN.1
syntax (they'll parse BER, and generate DER). You can define an
"AllPKIXMessages" class which, in ASN.1 terms would be a CHOICE of all the
defined PKIX messages. No coding is required (other than declaring a
CHOICE {} object). For example, if you've already defined classes
PKIXMessage1, PKIXMessage2, and PKIXMessage3, your AllPKIXMessages class
would be defined:
class AllPKIXMessages : public asn_choice {
public:
PKIXMessage1 m1;
PKIXMessage2 m2;
PKIXMessage3 m3;
AllPKIXMessages() {
register_child(&m1);
register_child(&m2);
register_child(&m3);
};
}
Provided the individual messages are structurally distinct, an object of
this class will be able to parse (or generate) any of the messages. This
works because (unlike ASN.1) the Jonah library doesn't insist on distinct
tags for the members of a CHOICE - they just have to be distinguishable
syntactically.
>In XML you can just determine the type by schema name. Isn't that
>much simpler?
Once you've used the above object to parse a message, you can ask it what
message type it read by calling its "selected()" member function which will
return 0 for a PKIXMessage1, 1 for a PKIXMessage2, etc. You can't get much
simpler than that.
John
---------------
Michael Ströder <michael@stroeder.com>@ms.inka.de on 11/16/2000 04:43:36 AM
Sent by: michael@ms.inka.de
To: ietf-pkix@imc.org
cc:
Subject: Re: Should PKIX protocols support XML well?
Peter Gutmann wrote:
>
> John_Wray@iris.com writes:
>
> >>- Immediately recognize the message type by its schema name as found
> >> by the parser.
>
> >The Jonah library can do that (recognize a message type either
implicitly by
> >its structure or explicitly by an embedded tag).
>
> My code does the same, throw any PKI-related object at it and it'll
recognise
> it automatically and process it as appropriate.
John, Peter, how does your code recognize any PKI-related object?
IMHO you're doing some kind of type probing, don't you?
In XML you can just determine the type by schema name. Isn't that
much simpler?
Ciao, Michael.
Received: from marcellus.entegrity.se ([195.100.88.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18014 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 06:03:59 -0800 (PST)
Received: from cooper.entegrity.com ([10.0.0.123]) by marcellus.entegrity.se (8.9.3/8.9.3) with ESMTP id PAA23659; Thu, 16 Nov 2000 15:06:50 +0100 (MET)
Message-Id: <5.0.1.4.0.20001116150714.02cb2050@exchsvr1.entegrity.com>
X-Sender: nada@exchsvr1.entegrity.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 16 Nov 2000 15:08:05 +0100
To: "Denis Pinkas" <Denis.Pinkas@bull.net>, "Rich Salz" <rsalz@caveosystems.com>
From: Nada Kapidzic Cicovic <nada@entegrity.com>
Subject: Re: OCSP identifiers
Cc: ietf-pkix@imc.org
In-Reply-To: <3A13B373.B4DA2D0D@bull.net>
References: <3A133C35.81D9649C@caveosystems.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 11:14 AM 11/16/00 +0100, Denis Pinkas wrote:
>Rich,
>
> > Be careful of sending the entire cert in a status or validity query. At a
> > previous employer it became pretty clear (with a patent attorney) that this
> > violated a patent held by Micali. No, I don't remember the number. But
> it was
> > a good thing that the OCSP syntax changed from the -02 draft. :)
> >
> > As for what identifiers to use, I always thought that requiring the
> issuer's
> > cert was onerous, and that sending the hash "for space reasons" was a bogus
> > argument. I further agree with Gutmann that it required weird indices
> on the
> > part of many implementors.
> >
> > I always thought {Issuer-DN, Subject-DN, Serial#} was relatively short
> and to
> > the point and unique.
>
>Not always unique. :-(
>
>... in case of an issuing key compromise. This is not important for queries
>about current certificates, but may be important as soon as the query would
>be for a certificate which was valid in the past. But the problem could be
>twisted in another way: should we really allow to query the status of a
>certificate in the past ? If we don't we avoid the problem, and, in such a
>case, I agree with you.
In my opinion it would be a pity to loose possibility of validating
certificates back in time.
Nada
>Denis
>
> > /r$
______________________________________________________________
Nada Kapidzic Cicovic, Ph.D.
Technical Director, Entegrity Solutions AB
office: + 46 8 477 77 37, cell: + 46 70 495 09 03, fax: + 46 8 477 77 31
Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA04445 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 05:22:13 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 08697088; Thu, 16 Nov 2000 08:29:35 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-13-202.bellatlantic.net [141.154.13.202]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id IAA30190; Thu, 16 Nov 2000 08:29:42 -0500
Message-ID: <3A13E1DE.780F8D07@caveosystems.com>
Date: Thu, 16 Nov 2000 08:32:14 -0500
From: Rich Salz <rsalz@caveosystems.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <Denis.Pinkas@bull.net>
CC: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <3A133C35.81D9649C@caveosystems.com> <3A13B373.B4DA2D0D@bull.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
> Not always unique. :-(
>
> .. in case of an issuing key compromise.
So what kind of identifier *is* unique in the case of issuer compromise?
The hash of the (subject) cert, provided your query is about a time *before*
the compromise, of course. Gee, it sure would be convenient if I could ask
about a cert, the issuer, and so on all the way up the chain with a single
query. Anyone given thought to doing that? :)
Sorry, bad joke.
/r$
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24816 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 04:50:16 -0800 (PST)
Received: from mega (t1o69p39.telia.com [62.20.144.39]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id NAA24819; Thu, 16 Nov 2000 13:57:47 +0100 (CET)
Message-ID: <016a01c04fcc$a0598d40$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Jean-Marc Desperrier" <jean-marc.desperrier@certplus.com>, "ietf-pkix" <ietf-pkix@imc.org>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <3A139374.B6BDD00E@nma.com> <015001c04fc3$3ba8d030$0201a8c0@vincent.se> <3A13CCD5.9E0747F2@certplus.com>
Subject: Re: Should PKIX protocols support XML well?
Date: Thu, 16 Nov 2000 13:56:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA24823
Jean-Marc,
> I think there is a definitive risk of name collision of schemas on a large scale.
Even If every person on this planet makes a billion schemas per day I can't see
that name-space is global a problem. Locally anything can happen of course.
I would worry much more about ambiguous uses of OIDs due to their huge numbers,
ugly ("computer-friendly") look, and potential lack of local tracking.
But actually, whatever you do, if you have a lousy methodology, you will end up in deep s**t
sooner or later.
/anders
Received: from internet.across ([213.212.5.232]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA24287 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 04:48:38 -0800 (PST)
Received: FROM acrossw01.across BY internet.across ; Thu Nov 16 13:57:42 2000 +0100
Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id <WZ8X2S79>; Thu, 16 Nov 2000 13:54:17 +0100
Message-ID: <E5C2786F90B4D4119A200008C716F45D269F3B@acrossw01.acrosswireless.com>
From: Simon Tardell <simon.tardell@smarttrust.com>
To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>, Rich Salz <rsalz@caveosystems.com>
Cc: ietf-pkix@imc.org
Subject: RE: OCSP identifiers
Date: Thu, 16 Nov 2000 13:54:07 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
> > I always thought {Issuer-DN, Subject-DN, Serial#} was
> relatively short and to
> > the point and unique.
>
> Not always unique. :-(
>
> ... in case of an issuing key compromise.
The point made in the RFC (IIRC) is that you cannot gurantee uniqueness of
the issuer DN, so that the responder wouldn't know if the client was really
asking about the same issuer, however the issuer key will be (with a
reasonable degree of certitude) unique. I'm not sure I agree to the validity
of that argument though, the client has to make sure he trusts the correct
issuers in some other way anyway, and the point becomes moot.
I don't see how any of this protects against issuer key compromise (possibly
against issuer of issuer, but...).
Simon.
Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
simon.tardell@smarttrust.com, http://www.smarttrust.com
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA21255 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 04:38:29 -0800 (PST)
Received: from asn-1.com (user-2ivf6l0.dialup.mindspring.com [165.247.154.160]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id HAA22039 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 07:45:26 -0500 (EST)
Message-ID: <3A13CB26.6563D3E4@asn-1.com>
Date: Thu, 16 Nov 2000 06:55:18 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: Should PKIX protocols support XML well?
References: <97431154424428@kahu.cs.auckland.ac.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Gutmann wrote (in part):
>
> John_Wray@iris.com writes (partially):
>
snip
> >The Jonah ASN.1 library doesn't do much checking of restrictions, but that was
> >an implementation choice rather than something imposed upon us by ASN.1.
>
> Doing strict checking is a downside, not a feature. In my code I originally
> did strict checking for compliance to RFC 2459, but found that there were so
> many certs which fail the checks that I probably spent more time adding
> special-case code to handle exceptions than in writing the cert-parsing code (I
Certainly the only sane approach to decoding. And
not getting hung up on enforcing DER restrictions
on BER is a good idea, too.
Enforcing constraints and restrictions is best left
to encoding, where you might want to be careful in
what values you send to others. But even encoding
enforcement is sometimes best relaxed, leaving this
to the underlying application code.
ASN.1 only defines what should be on the line, not
how it gets there.
Phil
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA18855 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 04:30:30 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA13116; Thu, 16 Nov 2000 13:44:01 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id NAA18514; Thu, 16 Nov 2000 13:37:26 +0100
Message-ID: <3A13D509.D040F7D1@bull.net>
Date: Thu, 16 Nov 2000 13:37:29 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <MMyers@verisign.com>
CC: ietf-pkix@imc.org
Subject: Re: DPV vs SCVP
References: <2F3EC696EAEED311BB2D009027C3F4F401C5B5A3@vhqpostal.verisign.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael,
My original text contains several arguments; many of them do have no direct
answer in your reply. Please, next time, use my original text to reply.
Nevertheless, see my responses embedded in you new text.
> Denis,
>
> Thanks for your in-depth review and comments on OCSPv2, both here and in
> your off-list communications. To my reading, you have four points:
>
> Replace "good" with "not revoked"
> ---------------------------------
> The last call for comments on the I-D that led to RFC2560 occurred roughly
> two years ago.
This is not an argument. The mis-use of "good", you currently make, is now
there to prove that there is a problem. Once again here is the text I
posted, on which you have not responded:
Extensions allows to request new services. The request for each every new
service may fail or succeed. This means that each extension will have to
carry the result of the request for the new service. This also means that
the current status will only carry the response to a *status revocation
request*, but will not carry any additional meaning. "Good" is not the
appropriate term to be used: "not revoked" is the right term and should be
used instead, when we revised OCSP.
> Replace "unknown" with "revocation status unknown"
> --------------------------------------------------
> See above.
The same.
> It should not be manadatory to implement revocation status.
> -----------------------------------------------------------
> RFC2560 asserts that servers SHALL implement revocation status. In other
> words, "shall be capable of" in order to ensure a minimum level of
> interoperability across the Internet. It does not however require
> deployment or activation of this functionality. Does this clarification
> satisfy your concern?
This is not what I said. Here is my original text:
" The real advantage to add DPV and DPD to OCSP is to be able to support
both
a revocation status request and DPV or DPV+DPD in a single request. It
should however be noticed that a response to a status revocation request is
not mandatory since the server may well return a "revocation status unknown"
response, but still respond to a DPD (Delegated Path Discovery) for the
certificate."
Besides the exact wording, I would guess that we agree in principle on that
point.
> An alternative ASN.1 syntax that preserves compatibility.
> ------------------------------------------------------------
> This one is worth some discussion on the list since it's at the core of what
> OCSPv2 is all about. The syntax that the OCSPv2 I-D proposes equally
> intends to address backwards interoperability concerns. It was informed by
> the approach CMS took in addressing the same issue. May I assume Denis that
> you have no issue with the I-D's version number treatment?
>
> Maybe the ASN.1 wizards out there could lend a hand here. For ease of
> analysis, we have:
>
> OCSPv2 -00 draft:
> -----------------
> Request ::= SEQUENCE {
> reqCert ReqCert,
> singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
>
> ReqCert ::= CHOICE {
> certID CertID,
> issuerSerial [0] IssuerandSerialNumber,
> pKCert [1] Certificate,
> name [2] GeneralName }
>
> CertID ::= SEQUENCE {
> hashAlgorithm AlgorithmIdentifier,
> issuerNameHash OCTET STRING, -- Hash of Issuer's DN
> issuerKeyHash OCTET STRING, -- Hash of Issuers public key
> serialNumber CertificateSerialNumber }
>
> Version ::= INTEGER { v1(0), v2(1) }
>
> "If certID is used in ReqCert, the version number used SHALL be v1. If
> any
> other identifier is used, the version number used SHALL be v2."
>
> Denis proposes:
> ---------------
> Request ::= SEQUENCE {
> reqCert CertID,
> singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
>
> CertID ::= SEQUENCE {
> hashAlgorithm AlgorithmIdentifier,
> issuerNameHash OCTET STRING, -- Hash of Issuer's DN
> issuerKeyHash OCTET STRING, -- Hash of Issuers public key
> serialNumber CertificateSerialNumber,
> certHash OCTET STRING OPTIONAL,
> pKCert Certificate OPTIONAL }
>
> while, for completeness, RFC2560 states:
> -----------------------------------------
> Request ::= SEQUENCE {
> reqCert CertID,
> singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
>
> CertID ::= SEQUENCE {
> hashAlgorithm AlgorithmIdentifier,
> issuerNameHash OCTET STRING, -- Hash of Issuer's DN
> issuerKeyHash OCTET STRING, -- Hash of Issuers public key
> serialNumber CertificateSerialNumber }
>
> The certHash option could be useful. We chose not to include it to minimize
> complexity. We included a GeneralName option for environments that are best
> enabled to PKI via Web-based naming schemes.
This is fairly insecure, hence why I have not kept that option.
> Given those observations, it
> seems that we have either six or half a dozen. It's still not clear to me
> how your alternative formulation improves backwards interoperability beyond
> that already proposed. Or am I overlooking something? Because I'm
> otherwise strongly inclined to leave things as they are.
The explanations are the following:
If someone has implemented an OCSP v1 client, it can simply turn it into an
OCSP v2 client by only changing the version number in the protocol. Of
course, there will be no added functionality, but the advantage is that it
can then talk to an OCSP v2 server.
Since you privately mentionned that OCSP v2 would replace OCSP v1 (the draft
v2 is not clear on that point), it is an easy move.
With the current structure proposed in OCSP v2, this cannot be done, since
the structure of the request is fairly different.
So my proposal is constructed in the following way:
1) keep the current structure of the request,
2) add optional fields in CertID which carry the possibility to identify a
certificate through "other means", e.g.:
certHash OCTET STRING OPTIONAL,
pKCert Certificate OPTIONAL
Note: If Rich things that using pKCert infringes a patent, we should
investigate this issue (or get rid of it).
This is the principle of the approach. If someone thinks that an additional
mean to identify a certificate should be added, it could be added to this
list as another optional element.
It maybe the right time to mention that I have never be pleased by using:
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
instead of the issuer DN.
The argument given at this time was the following: since the server has some
private agreements with a CA he is working for, it knows their names and
then can compute the hash of that name. If the service that is requested is
only a path discovery, then the argument does not stand anymore, since the
server may have access to a large number of certificates which are
identified by their name, not their hash. Adding "issuer" to the list of
optional parameters would thus make sense.
Besides the ASN.1, explanations would need to be given to tell which
combinations of these parameters make sense. The problem is that for the
basic service (i.e. a simple revocation status request), some combination
may be fine, but not sufficient for additional services (supported through
extensions). So we would have to anticipate the needs for these extensions.
In order to make sure we do not miss anything, a study should be done, at
least for the three services that we are attempting to support, to explain
and identify which combinations of these parameters are needed and thus make
sense.
I hope these explanations help.
Denis
> Mike
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08749 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 03:56:05 -0800 (PST)
Received: from certplus.com ([192.168.212.171]) by certplus.com (8.8.7/8.8.7) with ESMTP id NAA04819 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 13:08:25 +0100
Message-ID: <3A13CCD5.9E0747F2@certplus.com>
Date: Thu, 16 Nov 2000 13:02:29 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well?
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <3A139374.B6BDD00E@nma.com> <015001c04fc3$3ba8d030$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote:
> > ASN.1 and OIDs are based on hierarchical design rules, central control. XML is
> > based on local control. Both control paradigms are useful but, in many cases,
> > central control beats local control hands down in terms of security.
>
> XML schemas stored and maintained on a secure server run by a trusted party offers
> the possibility to have central control. Which makes sense for *some* apps.
I think there is a definitive risk of name collision of schemas on a large scale.
> OIDs are inherently less flexible. And need "educated" parsers.
>
> An example: W2K CryptoAPI returns "OID.2.5.4.5=xyz" instead of "SerialNumber=xyz" so at
> least MSFT has some "education" left to do...
Sure. MSFT tools just seems to have no idea what the OID identified as "Microsoft
Commercial Code Signing" by other tools is.
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04535 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 03:43:01 -0800 (PST)
Received: from mega (t1o69p39.telia.com [62.20.144.39]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id MAA02878; Thu, 16 Nov 2000 12:50:33 +0100 (CET)
Message-ID: <015001c04fc3$3ba8d030$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Ed Gerck" <egerck@nma.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>, "David P. Kemp" <dpkemp@missi.ncsc.mil>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <3A139374.B6BDD00E@nma.com>
Subject: Re: Should PKIX protocols support XML well?
Date: Thu, 16 Nov 2000 12:49:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA04540
Ed,
> but one point seem to be missed.
> ASN.1 and OIDs are based on hierarchical design rules, central control. XML is
> based on local control. Both control paradigms are useful but, in many cases,
> central control beats local control hands down in terms of security.
XML schemas stored and maintained on a secure server run by a trusted party offers
the possibility to have central control. Which makes sense for *some* apps.
OIDs are inherently less flexible. And need "educated" parsers.
An example: W2K CryptoAPI returns "OID.2.5.4.5=xyz" instead of "SerialNumber=xyz" so at
least MSFT has some "education" left to do...
Anders
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02590 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 03:37:54 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA01201; Thu, 16 Nov 2000 03:45:25 -0800 (PST)
Received: from sun.com (boston [129.156.220.153]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id LAA17647; Thu, 16 Nov 2000 11:45:24 GMT
Sender: Sean.Mullan@ireland.sun.com
Message-ID: <3A13C8D4.D23F4C8C@sun.com>
Date: Thu, 16 Nov 2000 11:45:24 +0000
From: Sean Mullan <sean.mullan@sun.com>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <Denis.Pinkas@bull.net>
CC: ietf-pkix@imc.org
Subject: Re: JSR-000055 Certification Path API
References: <3A0FD6AD.611581A6@sun.com> <3A0FE965.B6C09500@bull.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA02594
I have updated the archive to also include a single pdf document
(named "api.pdf") containing the javadocs. See:
http://java.sun.com/aboutJava/communityprocess/review/jsr055/index.html
to download the zip file.
--Sean
Denis Pinkas wrote:
>
> Sean,
>
> Thanks for the information. Would it be possible to get a printable version
> of the whole document, e.g. *.pdf (or *.doc) which includes a fixed number
> of pages so that it becomes easier to point to the text to raise comments ?
>
> Denis
>
> > All,
> >
> > The Java Certification Path API is now available for Public
> > Review. This is a new Java API that is being specified using
> > the Java Community Process (see
> > http://java.sun.com/aboutJava/communityprocess for more info
> > on the process).
> >
> > This API is being targeted for inclusion in the next release (1.4)
> > of J2SE (Java 2 Platform, Standard Edition). The API includes interfaces
> > and classes for building and validating chains of certificates.
> >
> > The API is based on the existing Java Cryptography Architecture
> > (see http://java.sun.com/j2se/1.3/docs/guide/security/CryptoSpec.html)
> > which allows developers to create and plug in cryptographic service
> > providers supporting various algorithms. The API also includes
> > a set of algorithm-specific classes supporting the PKIX certification
> > path validation algorithm.
> >
> > The public review period closes on December 8. See the forwarded message
> > below for details on downloading the specification. Please send any
> > comments you may have to the email address "certpath-experts-lead@ireland.sun.com".
> > We expect that many of you will be interested in this API and we look
> > forward to your comments.
> >
> > Thanks,
> > Sean Mullan
> > Specification Lead for JSR055
> > Java Security and Networking
> > Sun Microsystems
> >
> > ----------------------------------------------------------------------------
> >
> > Objet: JSR-000055 Certification Path API
> > Date: Thu, 9 Nov 2000 15:06:26 -0800
> > De: Harold Ogle <Harold.Ogle@eng.sun.com>
> > Répondre-A: "Java Community Process (JCP) general information/announcement
> > list" <JCP-INTEREST@JAVA.SUN.COM>
> > A: JCP-INTEREST@JAVA.SUN.COM
> >
> > The Public Review Draft Specification for
> >
> > JSR-000055 Certification Path API
> >
> > is now available for Public Review from
> >
> > http://java.sun.com/jcp/review.html
> >
> > This public review closes on December 8, 2000.
> >
> > The Maintenance Review of the JSPA, JSR 909, will end on December 5.
> >
> > ===========================================================================
> > To unsubscribe, send email to listserv@java.sun.com and include in the body
> > of the message "signoff JCP-INTEREST". For general help, send email to
> > listserv@java.sun.com and include in the body of the message "help".
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA03669 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 02:07:09 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA14594; Thu, 16 Nov 2000 11:20:38 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA25590; Thu, 16 Nov 2000 11:14:08 +0100
Message-ID: <3A13B373.B4DA2D0D@bull.net>
Date: Thu, 16 Nov 2000 11:14:11 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Rich Salz <rsalz@caveosystems.com>
CC: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <3A133C35.81D9649C@caveosystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rich,
> Be careful of sending the entire cert in a status or validity query. At a
> previous employer it became pretty clear (with a patent attorney) that this
> violated a patent held by Micali. No, I don't remember the number. But it was
> a good thing that the OCSP syntax changed from the -02 draft. :)
>
> As for what identifiers to use, I always thought that requiring the issuer's
> cert was onerous, and that sending the hash "for space reasons" was a bogus
> argument. I further agree with Gutmann that it required weird indices on the
> part of many implementors.
>
> I always thought {Issuer-DN, Subject-DN, Serial#} was relatively short and to
> the point and unique.
Not always unique. :-(
... in case of an issuing key compromise. This is not important for queries
about current certificates, but may be important as soon as the query would
be for a certificate which was valid in the past. But the problem could be
twisted in another way: should we really allow to query the status of a
certificate in the past ? If we don't we avoid the problem, and, in such a
case, I agree with you.
Denis
> /r$
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01961 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 02:02:41 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id D84BF683C7 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 11:03:20 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A13B0E8.FC7A6931@stroeder.com>
Date: Thu, 16 Nov 2000 11:03:20 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: PKIX-List <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well?
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote:
>
> The OID-stuff is AFAIK much more complicated (=error-prone) to administer than to
> agree on a schema name space and accompanying tags.
Anders, I totally agree.
Ciao, Michael.
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01960 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 02:02:41 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 6F1DF683C4 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 10:43:38 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A13AC48.B2F03709@stroeder.com>
Date: Thu, 16 Nov 2000 10:43:36 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: Should PKIX protocols support XML well?
References: <97431154424428@kahu.cs.auckland.ac.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Gutmann wrote:
>
> John_Wray@iris.com writes:
>
> >>- Immediately recognize the message type by its schema name as found
> >> by the parser.
>
> >The Jonah library can do that (recognize a message type either implicitly by
> >its structure or explicitly by an embedded tag).
>
> My code does the same, throw any PKI-related object at it and it'll recognise
> it automatically and process it as appropriate.
John, Peter, how does your code recognize any PKI-related object?
IMHO you're doing some kind of type probing, don't you?
In XML you can just determine the type by schema name. Isn't that
much simpler?
Ciao, Michael.
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01962 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 02:02:41 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id B8457683C8 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 11:09:36 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A13B260.95298157@stroeder.com>
Date: Thu, 16 Nov 2000 11:09:36 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: PKIX-List <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well?
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <3A139374.B6BDD00E@nma.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ed Gerck wrote:
>
> ASN.1 and OIDs are based on hierarchical design rules, central control. XML is
> based on local control.
Ed, OIDs are subject of local control either.
If you disagree please show me the mechanism how my application can
locate and download the machine-readable ASN.1 definition related to
an arbitrary OID.
Ciao, Michael.
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01958 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 02:02:41 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 43D09683C6 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 11:01:53 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A13B091.F49202FB@stroeder.com>
Date: Thu, 16 Nov 2000 11:01:53 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: PKIX is too complicated (was: Should PKIX protocols support XML well?)
References: <97431154424428@kahu.cs.auckland.ac.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
HI!
Disclaimer: I subscribed to this list because I began to write my
own poor-man's cert library in Python mainly for getting full access
to the cert extensions from my Python application. So I'm the
typical newbie PKIX implementor seeking for the fastest solution to
get his problem solved.
Peter Gutmann wrote:
>
> Doing strict checking is a downside, not a feature.
Talking about implementing PKIX today I agree.
But talking about defining fool-proof PKIX standards I completely
disagree. It should be mandantory in the future that a
PKIX-compliant application should simply reject PKI-related objects
not compliant to the PKIX-standards. And the schema-checking should
be as simple as possible to implement.
> In my code I originally
> did strict checking for compliance to RFC 2459, but found that there were so
> many certs which fail the checks that I probably spent more time adding
> special-case code to handle exceptions than in writing the cert-parsing code (I
> remember posting a rant to this list some time ago where I noted that of 11
> certs grabbed off the net, 10 failed to verify using the RFC 2459
> requirements).
Peter, this is a very important point!
As a bloody beginner in implementing the X.509-based stuff I'm very
frustrated because for lots of test certs which I collected I had to
add extra code to work around structures not compliant to RFC 2459.
And currently I'm just displaying the certs!
But instead of solely blaiming all those implementors for their
non-compliant certs / libs (which is somewhat true off course) the
PKIX working group should rethink their approach and try to make
things *simpler* in the future to avoid implementation errors by
stricter definitions. IMHO there are too many possibilities to
define certificate profiles today.
What I've learned in the security field (mainly firewalling etc.)
the main goal when wanthing security is:
Keep it as simple as possible to get a secure system.
IMHO all this PKIX standards today leave too much room for
implementors decisions and this will lead to a lot of insecure
implementations mentioned on BUGTRAQ...
> This stuff is hardly rocket science, just because XML is what they're wearing
> in Paris this year doesn't mean we should throw away years of experience and
> implementation work to chase the latest fad which comes along.
But refering to a schema by name is quite handy and fool-proof =>
simpler => more secure.
Ciao, Michael.
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01959 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 02:02:41 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 6C1E4683C3 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 10:20:58 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A13A6FA.B5CD7258@stroeder.com>
Date: Thu, 16 Nov 2000 10:20:58 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: OCSP identifiers
References: <3A133C35.81D9649C@caveosystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rich Salz wrote:
>
> I always thought {Issuer-DN, Subject-DN, Serial#} was relatively short and to
> the point and unique.
Rich, you're damn right! But this would be too easy... (Sigh! ;-)
Ciao, Michael.
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01465 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 02:01:18 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA22748; Thu, 16 Nov 2000 11:14:46 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA25396; Thu, 16 Nov 2000 11:07:56 +0100
Message-ID: <3A13B1FE.917EE85A@bull.net>
Date: Thu, 16 Nov 2000 11:07:58 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tom Gindin/Watson/IBM <tgindin@us.ibm.com>
CC: Steve Hanna <steve.hanna@sun.com>, ietf-pkix@imc.org
Subject: Re: Holder
References: <OF45ED8E84.6417B69F-ON85256998.00584C5A@somers.hqregion.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom,
> I don't have a specific example of an AC accompanying a signed
> document or transaction, either with or without a PKC.
Such a case is described in:
http://www.imc.org/draft-ietf-smime-esformats
This document, called "Electronic Signature formats", explains (among other
things) how to attach an AC to a signed document or transaction. It is being
progressed in the S/MIME working group and reflects the work being performed
by ETSI on that topic.
> In fact, AFAIK
> there is no place in either CMS or XMLDSIG to put an AC, although AC's
> could go into the attributes (signed or unsigned) in CMS and into
> SignatureProperty in XMLDSIG.
An extension to support that property is described in the document.
Denis
> It is legal to specify an X509Data in
> XMLDSIG which does not contain the full PKC (see section 4.4.4 of
> http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/), and it is legal to
> omit a PKC from SignedData in CMS (see section 5.1 of RFC 2630) "if it is
> expected that recipients have an alternate means of obtaining necessary
> certificates".
> I am suggesting that these are reasonable places for an AC to go in a
> push scenario. However, I am not personally involved in any current
> development of software using AC's, so anyone who wishes to dismiss my
> opinions on these matters as pure theory may do so.
>
> Tom Gindin
>
> Steve Hanna <steve.hanna@sun.com> on 11/14/2000 02:57:58 PM
>
> To: Tom Gindin/Watson/IBM@IBMUS
> cc: ietf-pkix@imc.org
> Subject: Re: Holder
>
> Do you have a specific example where an AC whose Holder component was
> tied to a PKC would accompany a signed document (or other object) but
> the PKC would not? This seems somewhat unlikely to me.
>
> I don't mind recommending format 9 instead of format 5, based only on
> easier debugging and a suspicion that the entityName might some day be
> useful for finding the PKC. But I would be more comfortable if we had a
> specific scenario where the entityName is needed to find the PKC.
>
> -Steve
>
> Tom Gindin/Watson/IBM wrote:
> >
> > The primary use I can think of for format 7, 9, or 11 is to permit
> an
> > AC to accompany (or simply be stored with) a signed document,
> transaction,
> > or message without requiring the PKC to do so. The RP can then look up
> the
> > PKC. As I have stated before, in any case like this format 11 or format
> 9
> > is preferable to format 5. Formats 4 and 5 are appropriate when the PKC
> > accompanies the AC or precedes it in a protocol, but not otherwise.
> > Since format 9 (or format 11) is preferable to format 5 when the AC
> is
> > sent or stored independently of the PKC and also carries out all the
> > functions of format 5, I would replace your references to format 5 by
> > references to format 9 (or format 11). Formats 2, 4, and 9 make a
> > reasonable minimal set, as do 2, 4, and 11.
> >
> > Tom Gindin
> >
> > Steve Hanna <steve.hanna@sun.com> on 11/10/2000 10:56:55 AM
> >
> > To: ietf-pkix@imc.org
> > cc:
> > Subject: Re: Holder
> >
> > Well, my list of scenarios does not seem to be helping us resolve this
> > issue.
> >
> > I will make a specific proposal, seeking comments or consensus. Since
> > none of the scenarios demonstrates a need for hints in Holder formats
> > that include the objectDigestInfo component, I propose that we adopt the
> > following recommendation, which would be incorporated into the next
> > version of ac509 (along with text explaining the various formats, how
> > they must be handled for validation purposes, and why each one might be
> > preferred to the others).
> >
> > AC issuers SHOULD use only formats 2, 4, or 5. They MAY use other
> > formats, as necessary. AC verifiers SHOULD support formats 2, 4, and
> > 5 (subject to specific requirements and configuration). They MAY
> > support other formats.
> >
> > I welcome comments from others on this proposal. A good argument can be
> > made for replacing format 5 with format 9, if only for debugging
> > purposes. But I'd rather not recommend support for both, if possible.
> >
> > -Steve
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA25181 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 01:42:05 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA09290; Thu, 16 Nov 2000 10:55:30 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA23076; Thu, 16 Nov 2000 10:49:00 +0100
Message-ID: <3A13AD8F.544971B8@bull.net>
Date: Thu, 16 Nov 2000 10:49:03 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Steve Hanna <steve.hanna@sun.com>
CC: stephen.farrell@baltimore.ie, ietf-pkix@imc.org
Subject: Re: Cross-organizational ACs
References: <sa10f961.033@prv-mail20.provo.novell.com> <3A11BAAC.4140F4EF@sun.com> <3A126549.D617698A@baltimore.ie> <3A12AA3C.6F771B38@sun.com> <3A12AF55.279C2779@baltimore.ie> <3A12B13D.2BFBAD78@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Steve,
Since I am answering to the e-mail one by one, here is another comment.
> Stephen Farrell wrote:
> > > So I suggest that we omit AAControls from ac509prof.
> > > It adds substantial complexity with little value.
> >
> > It doesn't add any complexity since its in the "optional
> > to implement" section, just like attribute encryption. So,
> > if you want to, do it, if not, not. I think this was the
> > concensus of the WG at a number of meetings and on the
> > list discussion on the various revs of the I-D.
>
> It adds complexity to the spec. This makes it more difficult for
> implementers to decide what to implement. And, if they decide to
> implement this optional feature, it adds complexity to their
> implementation. It also makes it more difficult for customers to decide
> which features they need (since they will probably consult the RFC for
> guidance). IETF specs (especially a profile!) should be as simple as
> possible, but no simpler.
>
> I just wanted to point out that AAControls is not sufficient for
> cross-organizational ACs. If the consensus of the working group remains
> to be that the AAControls extension is still valuable,
Besides Stephen (and possibly the co-editors), it would be nice to know who
is (or is not) in favour of AAControls.
> I will certainly
> accept this judgement. If there is a sudden flurry of emails saying
> "take it out," that's fine with me, too. In either case, I will not
> implement AAControls myself.
The same for me. :-)
> And I will work on and think about a
> simplified version of X.509 delegation that could be included in a
> future AC profile.
If you plan to attend the next IETF meeting, I would like to have a chat
with you, so that we can possibly define such delegation schemes. No syntax
changes planed in the definition of ACs, simply the definition of rules on
how to use them in the context of delegation.
Denis
> -Steve
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22707 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 01:34:41 -0800 (PST)
Received: from certplus.com ([192.168.212.171]) by certplus.com (8.8.7/8.8.7) with ESMTP id KAA03427 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 10:47:19 +0100
Message-ID: <3A13ABC3.98EFFF1E@certplus.com>
Date: Thu, 16 Nov 2000 10:41:23 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Cross-organizational ACs
References: <sa10f961.033@prv-mail20.provo.novell.com> <3A11BAAC.4140F4EF@sun.com> <00e501c04ef2$e033b0b0$0201a8c0@vincent.se> <3A12B403.2165EE5B@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Steve Hanna wrote:
> > E-mail clients as verifiers are a real PITA. When I open
> > PKIX-messages from some people (who apparently run their own CAs) I
> > constantly get alert messages due to unknown CA etc.
>
> > Personally I see little point in S/MIME using ACs except maybe for
> > server-based apps where the trust configuration stuff becomes much
> > more manageble.
>
> Agreed. Most users probably won't need ACs with S/MIME. For military
> applications, it may be important.
A more useful model would be that the client warns you only when it has already
received email from the same domain and/or same person with a different CA that the
one used in the message.
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA19631 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 01:25:18 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA21730; Thu, 16 Nov 2000 10:38:43 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA27706; Thu, 16 Nov 2000 10:32:04 +0100
Message-ID: <3A13A997.4068C6DD@bull.net>
Date: Thu, 16 Nov 2000 10:32:07 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Steve Hanna <steve.hanna@sun.com>
CC: stephen.farrell@baltimore.ie, ietf-pkix@imc.org
Subject: Re: Cross-organizational ACs
References: <sa10f961.033@prv-mail20.provo.novell.com> <3A11BAAC.4140F4EF@sun.com> <3A126549.D617698A@baltimore.ie> <3A12AA3C.6F771B38@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Steve,
. See below.
> Stephen Farrell wrote:
> > Your summary is correct. The reason for the text being as it is now
> > is that the X.509 (2000) delegation model was felt to be much too
> > complex for an initial PKIX profile. AAControls was provided as
> > an attempt to provide some of the controls required in a simple
> > way.
>
> Unfortunately, AAControls does not provide the constraints that most
> organizations will need in order to recognize ACs from other
> organizations (constraints on attribute values, not just attribute
> types).
>
> Given this limitation, why keep AAControls at all? Wouldn't it be better
> to work on simplifying and profiling X.509 delegation for some future
> PKIX AC profile than to create a less functional duplicate system now
> and have to support it in the future?
>
> It is true that AAControls allows AC verifiers to recognize multiple AC
> issuers with only a single configured AA CA. But the crude nature of the
> constraints included in AAControls mean that all the AC issuers must be
> within a single trust domain (unless the crude constraints are
> sufficient, which isn't likely in my view). I don't think this feature
> is very valuable. So I suggest that we omit AAControls from ac509prof.
> It adds substantial complexity with little value.
I basically agree with you. I have been advocating this removal. The
compromise made with Stephen Farrell (who wanted it), has been to make it
optional in the specification. Nevertheless, a deletion of it would be fine
with me. :-)
Denis
> > So lets not open up the delegation can of worms, until someone
> > steps up with a simple, working solution for delegation of X.509
> > ACs.
>
> Agreed. Let's set aside delegation for now (at least in this forum). ACs
> have many uses that do not require delegation.
>
> -Steve
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26537 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 00:15:12 -0800 (PST)
Received: from mega (t5o69p7.telia.com [213.64.110.7]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA20071; Thu, 16 Nov 2000 09:22:42 +0100 (CET)
Message-ID: <009b01c04fa6$33b92130$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "PKIX-List" <ietf-pkix@imc.org>
Cc: "Michael Zolotarev" <mzolotarev@baltimore.com>, "Stephen Kent" <kent@bbn.com>, "David P. Kemp" <dpkemp@missi.ncsc.mil>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se> <3A139374.B6BDD00E@nma.com>
Subject: Re: Should PKIX protocols support XML well?
Date: Thu, 16 Nov 2000 09:21:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA26541
Just to prove my point.
*outside* of this crummy list, Warwick Ford and others have no problems pushing XML
for purposes that look *very* similar to PKIX's.
http://www.netegrity.com/news/press_releases/dom/2000/press_release_11_15b_00.html
So what are we waiting on? To get redundant? Obsolete?
Or give us a new WG!
Anders
Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA17068 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 23:50:37 -0800 (PST)
Received: (qmail 28518 invoked from network); 16 Nov 2000 07:58:01 -0000
Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 16 Nov 2000 07:58:01 -0000
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Thu, 16 Nov 2000 01:57:41 -0600
Message-ID: <3A139374.B6BDD00E@nma.com>
Date: Wed, 15 Nov 2000 23:57:40 -0800
From: Ed Gerck <egerck@nma.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: PKIX-List <ietf-pkix@imc.org>, "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: Should PKIX protocols support XML well?
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil> <003b01c04f9a$91b32ad0$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote:
> The OID-stuff is AFAIK much more complicated (=error-prone) to administer than to
> agree on a schema name space and accompanying tags.
>
> That alone, seems to justify turning to XML for things like ACs that may proliferate
> in a way that PKCs didn't have to. And OIDs lack a useful name unless the parser
> is "taught" to understand them. XML parsers dont have to be "educated".
This dialogue seems to be moving like angry ghosts, back and forth, but one
point seem to be missed.
ASN.1 and OIDs are based on hierarchical design rules, central control. XML is
based on local control. Both control paradigms are useful but, in many cases,
central control beats local control hands down in terms of security. Think of
a spy ring, for example -- local spies need to be "educated" by the spymaster
and there is no other way around. This is well-recognized in the intelligence
community, where people learn that they cannot trust that which they cannot
control. The Internet brings about the need for a different control paradigm, since
it presents cases where you need to trust that which you absolutely can never
control -- the other side of the communication channel, for example. Local control
won't cut it either because it does not solve the trust issue beyond the local
domain. XML tags may mean different things to different people.
Since neither control paradigm can represent what the Internet needs, another
control paradigm will need to be introduced sooner or later. I mentioned this
and provided examples some three years ago, using digital certificates as an
example. The study served also to identify several flaws caused both by the
central and the local control approaches when applied as certificate models.
The study is available in a new version at http://www.mcg.org.br/cert.htm
and http://www.thebell.net/papers/certover.pdf and other mirrors.
Regarding PKIX, it would be useful to have both ASN.1 and XML IMO, and then
something else too. Interoperation is the hallmark of a standard.
Cheers,
Ed Gerck
>
>
> Anders
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA24941 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 22:51:56 -0800 (PST)
Received: from mega (t4o69p30.telia.com [62.20.145.150]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id HAA15937; Thu, 16 Nov 2000 07:59:28 +0100 (CET)
Message-ID: <003b01c04f9a$91b32ad0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "PKIX-List" <ietf-pkix@imc.org>, "David P. Kemp" <dpkemp@missi.ncsc.mil>
References: <200011151348.IAA03172@roadblock.missi.ncsc.mil>
Subject: Re: Should PKIX protocols support XML well?
Date: Thu, 16 Nov 2000 07:58:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA24950
David,
(sorry for snippet of private mail but this one has a larger interest)
> What you ascribe to the XML profile is exactly how X.509 v3 certificates
> work. The body of the certificate is the "generic header", and extensions
> include generic capabilities (defined in X.509 itself), community
> capabilities (the AIA and SIA extensions defined in RFC 2459 but not in
> X.509), and local extensions which don't need to be published anywhere,
> all they need is an OID assigned to the organization that created (wrote
> the ASN.1 type definition of) the extension.
The OID-stuff is AFAIK much more complicated (=error-prone) to administer than to
agree on a schema name space and accompanying tags.
That alone, seems to justify turning to XML for things like ACs that may proliferate
in a way that PKCs didn't have to. And OIDs lack a useful name unless the parser
is "taught" to understand them. XML parsers dont have to be "educated".
Anders
Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA24794 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 22:51:33 -0800 (PST)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.11.0/8.11.0) with SMTP id eAG6tRf15657 for <ietf-pkix@imc.org>; Thu, 16 Nov 2000 15:55:27 +0900 (KST)
From: "Kwon, YongChul" <godslord@initech.com>
To: "PKIX Working Group" <ietf-pkix@imc.org>
Subject: possiblities of Null Certificate Template in CRMF
Date: Thu, 16 Nov 2000 15:58:25 +0900
Message-ID: <MHEHKLAAKBIHDAAIJMAFAEEOCGAA.godslord@initech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal
in RFC-2510 and 2511, there are some inconsistent comments about
POPOSigningKey structure. and I read RFC-2510bis01 - Appendix D,
found that the inconsistent comments were fixed.
but, I am still uncomfortable about the possiblities of Null
CertificateTemplate
in some cases(Especially in Initialization Request).
because EE could not offer any information about the new certificate in many
cases(because they don't know their assigned DN, and the other fields
of CertificateTemplate highly depend on the policy of the Authority.)
and I don't want to see the same public key twice or more in a message which
can make high vulnerablity of inconsistency and implementer to suffer from
dealing them. :-(
so, I think more verbose comments are needed in those cases.
Just let Certificate Template as null sequence in those cases?
What was your attention Adams? :-)
please comment me.
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20927 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 21:06:08 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id PAA07090; Thu, 16 Nov 2000 15:21:08 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <W0XV165Q>; Thu, 16 Nov 2000 16:11:52 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCAD5A0F9@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Anders Rundgren <anders.rundgren@telia.com>, Michael Zolotarev <mzolotarev@baltimore.com>, Paul Koning <pkoning@ironstream.com>
Cc: kent@bbn.com, ietf-pkix@imc.org
Subject: RE: Security with XML vs ASN.1. Was: Should PKIX protocols suppo rt XML well
Date: Thu, 16 Nov 2000 16:11:52 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Anders,
> > The profile defined by PKIX is as flexible as anything
> else, and using ASN1
> > makes no difference in this regards compared to XML.
>
> For market acceptance (=deployment) some people in this list
> do not share your views entirely.
>
I'm used to it. That's what a discussion list is for, right?
<snip>
> Windows won over OS/2 due to pre-install (default). XML will
> do the same with ASN.1.
But we are arguing oranges and apples here. XML will win over ASN in the
areas where XML fits best, and ASN is NOT USED AT ALL - business
communications and transactions. So XML is winning with no competitors,
virtually. Nobody is proposing to use ASN1 in that domain.
<snip>
>
> Pardon me for refraining to "marketing BS" but if the
> majority of PKIX still believe that schemas
> is a largely redundant feature created for an ignorant
> e-business developer community,
> marketing BS is all that is left... :-) :-)
Anders, I believe that "the majority of PKIX" firmly believes that schemas
is a brillian feature, no kidding, "created for an ignorant
e-business developer community". And a lot of other communities with
different levels of ignorance or advancement. And I don't recall anybody
saying that schemas are redundant. Not exactly necessary and brilliant as a
replacement for existing ASN-based approach in PKIX protocols - yes, some
people in this list did say it :)
Michael
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10163 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 20:36:36 -0800 (PST)
Received: from mega (t7o69p73.telia.com [213.65.46.73]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id FAA20936; Thu, 16 Nov 2000 05:44:00 +0100 (CET)
Message-ID: <001e01c04f87$a5558b40$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Michael Zolotarev" <mzolotarev@baltimore.com>, "Paul Koning" <pkoning@ironstream.com>
Cc: <kent@bbn.com>, <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCAD5A06F@sydneymail1.jp.zergo.com.au>
Subject: Re: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
Date: Thu, 16 Nov 2000 05:42:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id UAA10170
Michael,
> Why do you say "predefined"?
> The draft says: "Some standard attribute types are defined in section 4.5."
> <<BTW it must be 4.4. Editorial.>>
>
> It does not imply that these attributes, all or some of them, must be
> present in every AC. By no means so. An AC may contain a single attribute
> called "MyDog'sMumMaidenName".
Pre-defined refers to the fact that they have OIDs already while other types
requires new OIDs.
> The profile defined by PKIX is as flexible as anything else, and using ASN1
> makes no difference in this regards compared to XML.
For market acceptance (=deployment) some people in this list do not share your views entirely.
On a hard-core bit-level you are right. But you still don't have an ASN.1 schema and
even if there is one, there is no support in my computer, nor in java AFAIK.
When will you make this available? Will Bill put in W2K? Not a chance in hell!
Windows won over OS/2 due to pre-install (default). XML will do the same with ASN.1.
I told OS/2 "zelots" that Windows would win *years* before it actually did. I was always
put down by their view that OS/2 was so much better, that Windows would have no chance.
I said sure, but if it is not on most computers by default it will stay marginal. In spite of
possible technical advantages.
Pardon me for refraining to "marketing BS" but if the majority of PKIX still believe that schemas
is a largely redundant feature created for an ignorant e-business developer community,
marketing BS is all that is left... :-) :-)
Anders
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24756 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 19:44:03 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id NAA06351; Thu, 16 Nov 2000 13:59:00 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <W0WZT42V>; Thu, 16 Nov 2000 14:49:44 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCAD5A06F@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Anders Rundgren <anders.rundgren@telia.com>, Paul Koning <pkoning@ironstream.com>
Cc: kent@bbn.com, ietf-pkix@imc.org
Subject: RE: Security with XML vs ASN.1. Was: Should PKIX protocols suppo rt XML well
Date: Thu, 16 Nov 2000 14:49:42 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
>
> AttributeCertificateInfo ::= SEQUENCE {
> version AttCertVersion DEFAULT v1,
> holder Holder,
> issuer AttCertIssuer,
> signature AlgorithmIdentifier,
> serialNumber CertificateSerialNumber,
> attrCertValidityPeriod AttCertValidityPeriod,
> // PKIX:
> attributes SEQUENCE OF Attribute,
> // XML-AC:
> attributes
> embedded-XML-data-using-a-unique-identifyable-app-defined-attr
> ibute-schema,
> // No
> predefined attributes (or extensions) whatsoever
>
Anders,
Why do you say "predefined"?
The draft says: "Some standard attribute types are defined in section 4.5."
<<BTW it must be 4.4. Editorial.>>
It does not imply that these attributes, all or some of them, must be
present in every AC. By no means so. An AC may contain a single attribute
called "MyDog'sMumMaidenName".
The profile defined by PKIX is as flexible as anything else, and using ASN1
makes no difference in this regards compared to XML.
M
Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21138 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 17:35:42 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 06269677 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 20:42:42 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-13-202.bellatlantic.net [141.154.13.202]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id UAA29241 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 20:42:59 -0500
Message-ID: <3A133C35.81D9649C@caveosystems.com>
Date: Wed, 15 Nov 2000 20:45:25 -0500
From: Rich Salz <rsalz@caveosystems.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: OCSP identifiers
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
Be careful of sending the entire cert in a status or validity query. At a
previous employer it became pretty clear (with a patent attorney) that this
violated a patent held by Micali. No, I don't remember the number. But it was
a good thing that the OCSP syntax changed from the -02 draft. :)
As for what identifiers to use, I always thought that requiring the issuer's
cert was onerous, and that sending the hash "for space reasons" was a bogus
argument. I further agree with Gutmann that it required weird indices on the
part of many implementors.
I always thought {Issuer-DN, Subject-DN, Serial#} was relatively short and to
the point and unique.
/r$
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28167 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 16:04:20 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA161270; Wed, 15 Nov 2000 19:11:17 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id TAA111120; Wed, 15 Nov 2000 19:10:38 -0500
Importance: Normal
Subject: Re: Holder
To: Steve Hanna <steve.hanna@sun.com>
Cc: ietf-pkix@imc.org
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF45ED8E84.6417B69F-ON85256998.00584C5A@somers.hqregion.ibm.com>
From: "Tom Gindin/Watson/IBM" <tgindin@us.ibm.com>
Date: Wed, 15 Nov 2000 19:11:48 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.5 |September 22, 2000) at 11/15/2000 07:11:50 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
I don't have a specific example of an AC accompanying a signed
document or transaction, either with or without a PKC. In fact, AFAIK
there is no place in either CMS or XMLDSIG to put an AC, although AC's
could go into the attributes (signed or unsigned) in CMS and into
SignatureProperty in XMLDSIG. It is legal to specify an X509Data in
XMLDSIG which does not contain the full PKC (see section 4.4.4 of
http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/), and it is legal to
omit a PKC from SignedData in CMS (see section 5.1 of RFC 2630) "if it is
expected that recipients have an alternate means of obtaining necessary
certificates".
I am suggesting that these are reasonable places for an AC to go in a
push scenario. However, I am not personally involved in any current
development of software using AC's, so anyone who wishes to dismiss my
opinions on these matters as pure theory may do so.
Tom Gindin
Steve Hanna <steve.hanna@sun.com> on 11/14/2000 02:57:58 PM
To: Tom Gindin/Watson/IBM@IBMUS
cc: ietf-pkix@imc.org
Subject: Re: Holder
Do you have a specific example where an AC whose Holder component was
tied to a PKC would accompany a signed document (or other object) but
the PKC would not? This seems somewhat unlikely to me.
I don't mind recommending format 9 instead of format 5, based only on
easier debugging and a suspicion that the entityName might some day be
useful for finding the PKC. But I would be more comfortable if we had a
specific scenario where the entityName is needed to find the PKC.
-Steve
Tom Gindin/Watson/IBM wrote:
>
> The primary use I can think of for format 7, 9, or 11 is to permit
an
> AC to accompany (or simply be stored with) a signed document,
transaction,
> or message without requiring the PKC to do so. The RP can then look up
the
> PKC. As I have stated before, in any case like this format 11 or format
9
> is preferable to format 5. Formats 4 and 5 are appropriate when the PKC
> accompanies the AC or precedes it in a protocol, but not otherwise.
> Since format 9 (or format 11) is preferable to format 5 when the AC
is
> sent or stored independently of the PKC and also carries out all the
> functions of format 5, I would replace your references to format 5 by
> references to format 9 (or format 11). Formats 2, 4, and 9 make a
> reasonable minimal set, as do 2, 4, and 11.
>
> Tom Gindin
>
> Steve Hanna <steve.hanna@sun.com> on 11/10/2000 10:56:55 AM
>
> To: ietf-pkix@imc.org
> cc:
> Subject: Re: Holder
>
> Well, my list of scenarios does not seem to be helping us resolve this
> issue.
>
> I will make a specific proposal, seeking comments or consensus. Since
> none of the scenarios demonstrates a need for hints in Holder formats
> that include the objectDigestInfo component, I propose that we adopt the
> following recommendation, which would be incorporated into the next
> version of ac509 (along with text explaining the various formats, how
> they must be handled for validation purposes, and why each one might be
> preferred to the others).
>
> AC issuers SHOULD use only formats 2, 4, or 5. They MAY use other
> formats, as necessary. AC verifiers SHOULD support formats 2, 4, and
> 5 (subject to specific requirements and configuration). They MAY
> support other formats.
>
> I welcome comments from others on this proposal. A good argument can be
> made for replacing format 5 with format 9, if only for debugging
> purposes. But I'd rather not recommend support for both, if possible.
>
> -Steve
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA20298 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 14:57:33 -0800 (PST)
Received: from mega (t4o69p90.telia.com [62.20.145.210]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id AAA22516; Thu, 16 Nov 2000 00:04:58 +0100 (CET)
Message-ID: <02bb01c04f58$48038340$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Paul Koning" <pkoning@ironstream.com>
Cc: <kent@bbn.com>, <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com><v04220805b635ea7c6b39@[171.78.30.107]><008501c04dca$78a3b0e0$0201a8c0@vincent.se><v04220800b636f37d3545@[171.78.30.108]><006701c04e5e$4891f030$0201a8c0@vincent.se><v0422080fb637aa9c4f99@[171.78.30.108]><005201c04ee0$9a2b8c80$0201a8c0@vincent.se><v04220803b6387a794320@[128.33.238.44]><024901c04f3b$c777b5f0$0201a8c0@vincent.se> <14867.2120.347752.256147@pkoning.ironstream.com>
Subject: Re: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
Date: Thu, 16 Nov 2000 00:03:33 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA20301
Paul,
> Anders> Using XML app-schemas you would not do that. Well, somebody
> Anders> have to write the app-schema. ONCE. And will contain just
> Anders> the stuff needed for that app. If the "ASN.1 camp" can do
> Anders> distributable app-shemas, fine. It is odd though that they
> Anders> currently don't except at laboratory level. The "XML camp"
> Anders> do this in production. Today.
>
> If the schema is already defined before you discover the need to
> implement the restriction, don't you have the same problem?
The app-developer community (not PKIX) defines in (an hopefully) collaborative way
*exactly* what their particular app needs so I really don't understand the question.
Such a community can be a person, a nation, an organization, whatever.
If somebody needs a restriction they must ask the appropriate community for a revision
(=new schema) instead of imposing a local restriction that would break every now and then
when fed with other's (potentially unrestricted) data.
If they only use things locally they define their own schema = app. By *design* auto-rejects
anything else.
At the same time extremely rigid, extremely flexible, *and* secure.
Clearances, userids, authorizations, tickets, coupons etc. IMO benefit by such a model.
Yes, I know that this is contrary to the golden rule: Be tolerant with what you receive, be strict
with what you send.
Using schemas you [the app community] can be as strict (or sloppy if that is what you want), as required by
the app. The lower limit is that you don't accept data based on a schema "you are not programmed for".
Below is a revised AC showing "in principle" what I suggest (although I would skip ASN.1 completely):
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion DEFAULT v1,
holder Holder,
issuer AttCertIssuer,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod,
// PKIX:
attributes SEQUENCE OF Attribute,
// XML-AC:
attributes embedded-XML-data-using-a-unique-identifyable-app-defined-attribute-schema,
// No predefined attributes (or extensions) whatsoever
issuerUniqueID UniqueIdentifier OPTIONAL,
// The following would (if it would stay at all) refer to extensions of the generic (container) part
extensions Extensions OPTIONAL
}
Anders
Received: from jlc.net (3ff83a80.dsl.flashcom.net [63.248.58.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09093 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 13:56:22 -0800 (PST)
Received: (from pkoning@localhost) by jlc.net (8.9.3/8.8.7) id RAA07865; Wed, 15 Nov 2000 17:03:52 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14867.2120.347752.256147@pkoning.ironstream.com>
Date: Wed, 15 Nov 2000 17:03:52 -0500 (EST)
From: Paul Koning <pkoning@ironstream.com>
To: anders.rundgren@telia.com
Cc: kent@bbn.com, ietf-pkix@imc.org
Subject: Re: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]> <006701c04e5e$4891f030$0201a8c0@vincent.se> <v0422080fb637aa9c4f99@[171.78.30.108]> <005201c04ee0$9a2b8c80$0201a8c0@vincent.se> <v04220803b6387a794320@[128.33.238.44]> <024901c04f3b$c777b5f0$0201a8c0@vincent.se>
X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid
>>>>> "Anders" == Anders Rundgren <anders.rundgren@telia.com> writes:
Anders> Steve,
>> >Using an XML schema you know when you are going to act on
>> received data that: >- The elements that the app "knows" are
>> there. No more, no less >- The elements have the proper format.
>> I.e. no a 100k strings if >the schema says 80
>>
>> This is also enforced by ASN.1 compiler-generated structure
>> decoding code, so there's no feature difference here.
Anders> I know, but it is pretty to hard to do anything concering
Anders> attributes already defined in the AC draft. I.e. if your app
Anders> would like passwords to be max 80 bytes you must perform this
Anders> check at application-level (or rewriting AC).
Or you just tweak the standard ASN.1 file before submitting it to the
compiler. That's generally the easiest solution.
Anders> Using XML app-schemas you would not do that. Well, somebody
Anders> have to write the app-schema. ONCE. And will contain just
Anders> the stuff needed for that app. If the "ASN.1 camp" can do
Anders> distributable app-shemas, fine. It is odd though that they
Anders> currently don't except at laboratory level. The "XML camp"
Anders> do this in production. Today.
If the schema is already defined before you discover the need to
implement the restriction, don't you have the same problem?
If you're going to compare meaningfully, you must compare new files of
type A with new files of type B, not old (already frozen) files of
type A with newly written files of type B.
paul
Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07495 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 13:00:40 -0800 (PST)
Received: from 208-58-192-224.s224.tnt9.lnhva.md.dialup.rcn.com ([208.58.192.224] helo=rankney) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.16 #5) id 13w9mr-0006nn-00 ; Wed, 15 Nov 2000 16:08:11 -0500
Message-ID: <002c01c04f48$8575bfa0$e0c03ad0@rankney>
From: "Rich Ankney" <rankney@erols.com>
To: "Michael Myers" <MMyers@verisign.com>, "Denis Pinkas" <Denis.Pinkas@bull.net>
Cc: <ietf-pkix@imc.org>
Subject: Re: DPV vs SCVP
Date: Wed, 15 Nov 2000 16:10:39 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
I prefer the first version of CertID, although I'm interested in hearing
more
from Denis about the difference in backward compatibility between the
two. I'd also like to see the certHash alternative in the first version (to
handle alternative cert formats like X9.68 that have no explicit issuer
and serial # fields). I COULD also do this using the "name" alternative
and defining an OTHER-NAME to carry the X9.68 "Owner" syntax.
This assumes the "name" alternative refers to the subject name of the
cert in question, but that begs the question of how to handle the case
where a subject has multiple (X.509) certs (with the same subject name).
Regards,
Rich
-----Original Message-----
From: Michael Myers <MMyers@verisign.com>
To: Denis Pinkas <Denis.Pinkas@bull.net>; Michael Myers
<MMyers@verisign.com>
Cc: ietf-pkix@imc.org <ietf-pkix@imc.org>
Date: Wednesday, November 15, 2000 1:14 PM
Subject: RE: DPV vs SCVP
>Denis,
>
>Thanks for your in-depth review and comments on OCSPv2, both here and in
>your off-list communications. To my reading, you have four points:
>
>Replace "good" with "not revoked"
>---------------------------------
>The last call for comments on the I-D that led to RFC2560 occurred roughly
>two years ago.
>
>
>Replace "unknown" with "revocation status unknown"
>--------------------------------------------------
>See above.
>
>
>It should not be manadatory to implement revocation status.
>-----------------------------------------------------------
>RFC2560 asserts that servers SHALL implement revocation status. In other
>words, "shall be capable of" in order to ensure a minimum level of
>interoperability across the Internet. It does not however require
>deployment or activation of this functionality. Does this clarification
>satisfy your concern?
>
>
>An alternative ASN.1 syntax that preserves compatibility.
>------------------------------------------------------------
>This one is worth some discussion on the list since it's at the core of
what
>OCSPv2 is all about. The syntax that the OCSPv2 I-D proposes equally
>intends to address backwards interoperability concerns. It was informed by
>the approach CMS took in addressing the same issue. May I assume Denis
that
>you have no issue with the I-D's version number treatment?
>
>Maybe the ASN.1 wizards out there could lend a hand here. For ease of
>analysis, we have:
>
> OCSPv2 -00 draft:
> -----------------
> Request ::= SEQUENCE {
> reqCert ReqCert,
> singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
>
> ReqCert ::= CHOICE {
> certID CertID,
> issuerSerial [0] IssuerandSerialNumber,
> pKCert [1] Certificate,
> name [2] GeneralName }
>
> CertID ::= SEQUENCE {
> hashAlgorithm AlgorithmIdentifier,
> issuerNameHash OCTET STRING, -- Hash of Issuer's DN
> issuerKeyHash OCTET STRING, -- Hash of Issuers public key
> serialNumber CertificateSerialNumber }
>
> Version ::= INTEGER { v1(0), v2(1) }
>
> "If certID is used in ReqCert, the version number used SHALL be v1. If
>any
> other identifier is used, the version number used SHALL be v2."
>
>
> Denis proposes:
> ---------------
> Request ::= SEQUENCE {
> reqCert CertID,
> singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
>
> CertID ::= SEQUENCE {
> hashAlgorithm AlgorithmIdentifier,
> issuerNameHash OCTET STRING, -- Hash of Issuer's DN
> issuerKeyHash OCTET STRING, -- Hash of Issuers public key
> serialNumber CertificateSerialNumber,
> certHash OCTET STRING OPTIONAL,
> pKCert Certificate OPTIONAL }
>
>
> while, for completeness, RFC2560 states:
> -----------------------------------------
> Request ::= SEQUENCE {
> reqCert CertID,
> singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
>
> CertID ::= SEQUENCE {
> hashAlgorithm AlgorithmIdentifier,
> issuerNameHash OCTET STRING, -- Hash of Issuer's DN
> issuerKeyHash OCTET STRING, -- Hash of Issuers public key
> serialNumber CertificateSerialNumber }
>
>
>The certHash option could be useful. We chose not to include it to
minimize
>complexity. We included a GeneralName option for environments that are
best
>enabled to PKI via Web-based naming schemes. Given those observations, it
>seems that we have either six or half a dozen. It's still not clear to me
>how your alternative formulation improves backwards interoperability beyond
>that already proposed. Or am I overlooking something? Because I'm
>otherwise strongly inclined to leave things as they are.
>
>Mike
>
>
Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06147 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 12:47:50 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <W5KZK9BM>; Wed, 15 Nov 2000 15:55:52 -0500
Message-ID: <DD62792EA182FF4E99C2FBC07E3053BD053E85@sottmxs09.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: ietf-pkix@imc.org, "'Ambarish Malpani'" <ambarish@valicert.com>
Subject: RE: Any OCSP implementations out there?
Date: Wed, 15 Nov 2000 15:54:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04F46.4DA26FD0"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C04F46.4DA26FD0
Content-Type: text/plain
Hi,
> ----------
> From: Ambarish Malpani[SMTP:ambarish@valicert.com]
> Sent: Wednesday, November 15, 2000 3:03 PM
> To: ietf-pkix@imc.org
> Subject: Any OCSP implementations out there?
>
> Hi Folks,
> I am looking for people who have OCSP currently implemented
> (either in products they are building or using).
>
> There is some feeling that the definition of CertID is not
> flexible enough and that OCSP, long term, would be better served
> by allowing the client to identify the cert in multiple ways -
> by CertID, by the full certificate, by a URL pointing to the
> certificate, etc.
>
> I am looking for some input from people who are currently using
> OCSP about whether they believe that this is an important
> enhancement to OCSP, or whether they are satisfied with it the
> way it is currently defined.
This question is worth asking and I am certainly interested in the responses
(or a summary) as well. However, I can't help but get the feeling that the
"people who are currently using OCSP" are more likely than not to have found
it adequate for their needs (otherwise they would not be currently using
it).
Therefore, it's probably worth also soliciting the opinions of any who
perhaps wanted to use OCSP and found it inadequate (and therefore didn't use
it) because the current CertID was too limiting for their
environment/purpose. Of course, I've no idea if that particular set of
people subscribe to PKIX, but we might as well at least ask the question...
Carlisle.
------_=_NextPart_001_01C04F46.4DA26FD0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Any OCSP implementations out there?</TITLE>
</HEAD>
<BODY>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Ambarish =
Malpani[SMTP:ambarish@valicert.com]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Wednesday, November 15, 2000 3:03 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">ietf-pkix@imc.org</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Any OCSP implementations out there?</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Folks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> I am looking for =
people who have OCSP currently implemented</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(either in products they are building =
or using).</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">There is some feeling that the =
definition of CertID is not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">flexible enough and that OCSP, long =
term, would be better served</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">by allowing the client to identify =
the cert in multiple ways -</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">by CertID, by the full certificate, =
by a URL pointing to the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certificate, etc.</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">I am looking for some input from =
people who are currently using</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">OCSP about whether they believe that =
this is an important</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">enhancement to OCSP, or whether they =
are satisfied with it the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">way it is currently defined.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman"> </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">This =
question is worth asking and I am certainly interested in the responses =
(or a summary) as well. However, I can't help but get the feeling =
that the "people who are currently using OCSP" are more =
likely than not to have found it adequate for their needs (otherwise =
they would not be currently using it).</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Therefore, =
it's probably worth also soliciting the opinions of any who perhaps =
wanted to use OCSP and found it inadequate (and therefore didn't use =
it) because the current CertID was too limiting for their =
environment/purpose. Of course, I've no idea if that particular =
set of people subscribe to PKIX, but we might as well at least ask the =
question...</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C04F46.4DA26FD0--
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05860 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 12:43:49 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id JAA04198; Thu, 16 Nov 2000 09:50:43 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97432145225787>; Thu, 16 Nov 2000 09:50:52 (NZDT)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: ambarish@valicert.com, ietf-pkix@imc.org
Subject: Re: Any OCSP implementations out there?
Sender: pgut001@cs.auckland.ac.nz
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 16 Nov 2000 09:50:52 (NZDT)
Message-ID: <97432145225787@kahu.cs.auckland.ac.nz>
Ambarish Malpani <ambarish@valicert.com> writes:
>There is some feeling that the definition of CertID is not flexible enough and
>that OCSP, long term, would be better served by allowing the client to
>identify the cert in multiple ways - by CertID, by the full certificate, by a
>URL pointing to the certificate, etc.
I've already grumbled about this in private, but I'm posting this to the list
in case others have any thoughts... when used in a request this is a really
serious, major PITA to work with because the issuerNameHash/serialNumber option
is useless (ie unless your implementation happens to already make use of the
issuerNameHash and serialNumber as search keys you can't do anything with the
combination of hashed and unhashed data), and the issuerKeyHash isn't the same
as the authorityKeyIdentifier (since there are many different interpretations
of how to construct the aKI) so you have to manually dig into the cert encoding
and construct it yourself rather than just keying off the aKI. I'd like to see
the CertID extended to also allow a cert hash, issuerAndSerialNumber (strictly
speaking an iAndS hash, you don't need the whole iAndS), and an aKI (that is,
an explicit aKI rather than an implicit RFC2459-style aKI as it's done now).
This could be done by making it a choice of the current certID and the above
values.
You also need to carefully consider just what you can put into a CertID, for
example by allowing URLs I can force the responder to access any web page I
want by telling it there's a cert there ("Hmm, the responder's running under NT
and using OCSP.OCX for the processing, should only take a minute before it's
under my control...").
Peter.
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28820 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 11:57:52 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4300C0114YED@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 15 Nov 2000 12:05:22 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4300B6I14YYZ@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 15 Nov 2000 12:05:22 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NL494>; Wed, 15 Nov 2000 12:03:20 -0800
Content-return: allowed
Date: Wed, 15 Nov 2000 12:03:09 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: Any OCSP implementations out there?
To: ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E152FFC@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Hi Folks,
I am looking for people who have OCSP currently implemented
(either in products they are building or using).
There is some feeling that the definition of CertID is not
flexible enough and that OCSP, long term, would be better served
by allowing the client to identify the cert in multiple ways -
by CertID, by the full certificate, by a URL pointing to the
certificate, etc.
I am looking for some input from people who are currently using
OCSP about whether they believe that this is an important
enhancement to OCSP, or whether they are satisfied with it the
way it is currently defined.
If people are reluctant to post to the whole group, please let me
know in a private email and I will happily summarize.
NOTE: This discussion only pertains to OCSP and is not asking
about whether remote path processing is valuable or not.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24886 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 11:45:47 -0800 (PST)
Received: from mega (t1o69p4.telia.com [62.20.144.4]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id UAA10993; Wed, 15 Nov 2000 20:53:11 +0100 (CET)
Message-ID: <024f01c04f3d$7d631a20$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>
Cc: <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]> <006701c04e5e$4891f030$0201a8c0@vincent.se> <007301c04ee9$360fde50$0201a8c0@vincent.se> <v04220804b6387bd1941e@[128.33.238.44]>
Subject: Re: Should PKIX protocols support XML well?
Date: Wed, 15 Nov 2000 20:51:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA24897
Steve,
> If your goal is to create a competing technology serving the same
> function as ACs, but based exclusively on XML, then I think it might
> be appropriate to create a new WG. Contact the Security ADs.
The goal is not to create a "competing" technolgy. But to build new exciting things
on the platform that many believe has a better chance to become mainstream than the
current one.
The scope would certainly not be restricted to ACs, but it could be a good "starter".
Anders
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24497 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 11:44:52 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4300C010JAAE@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 15 Nov 2000 11:52:22 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G4300BC00JAQK@ext-mail.valicert.com>; Wed, 15 Nov 2000 11:52:22 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NL463>; Wed, 15 Nov 2000 11:50:20 -0800
Content-return: allowed
Date: Wed, 15 Nov 2000 11:50:18 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: Should PKIX protocols support XML well
To: "'Stephen Kent'" <kent@bbn.com>, Russ Housley <housley@spyrus.com>
Cc: ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E152FFB@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Steve, if the goal was to keep the clients simple, I would think
that the server would need to support both XML and ASN.1.
For particular communities that wanted to do something closed,
they could mandate support for only one of the formats, but for the
open world, I would expect the server to bear the burden.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Wednesday, November 15, 2000 10:51 AM
> To: Russ Housley
> Cc: ietf-pkix@imc.org
> Subject: Re: Should PKIX protocols support XML well
>
>
> Russ,
>
> >Steve:
> >
> >I agree with both of your points. However, XML-enabled clients are
> >of interest when those clients are using XML digital signatures.
> >
> >I would like to see a solution where clients that are prepared to
> >deal with ASN.1 can get a signed response in the CMS format (RFC
> >2630), and clients that are prepared to deal with Signed XML can get
> >a response in that yet-to-be-finalized format.
>
>
>
> >Further, the XML client should be able to treat the X.509
> >certificate as an octet blob. They simply pass the certificate to
> >the trusted server, and the server returns a signed testament that
> >the certificate is valid, the public key, and alt names. There may
> >be other fields that should be returned, but we need to explore this
> >model further to understand what they might be.
> >
>
> That seems reasonable based on your examples, but how do you want to
> translate this into a standards requirement? If we made support for
> ASN.1 or XML formats mandatory and the other optional it would
> disadvantage one class of clients or the other. We can have two
> distinct standards and let vendors choose which one to support, but
> do we do that for both clients and servers, or do we plave the burden
> on servers to support both forms of requests and to generate both
> forms of responses?
>
> Steve
>
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22241 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 11:33:30 -0800 (PST)
Received: from mega (t1o69p4.telia.com [62.20.144.4]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id UAA01723; Wed, 15 Nov 2000 20:40:56 +0100 (CET)
Message-ID: <024901c04f3b$c777b5f0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>
Cc: <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]> <006701c04e5e$4891f030$0201a8c0@vincent.se> <v0422080fb637aa9c4f99@[171.78.30.108]> <005201c04ee0$9a2b8c80$0201a8c0@vincent.se> <v04220803b6387a794320@[128.33.238.44]>
Subject: Re: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
Date: Wed, 15 Nov 2000 20:39:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA22242
Steve,
> >Using an XML schema you know when you are going to act on received data that:
> >- The elements that the app "knows" are there. No more, no less
> >- The elements have the proper format. I.e. no a 100k strings if
> >the schema says 80
>
> This is also enforced by ASN.1 compiler-generated structure decoding
> code, so there's no feature difference here.
I know, but it is pretty to hard to do anything concering attributes already defined
in the AC draft. I.e. if your app would like passwords to be max 80
bytes you must perform this check at application-level (or rewriting AC).
Using XML app-schemas you would not do that. Well, somebody have to write
the app-schema. ONCE. And will contain just the stuff needed for that app.
If the "ASN.1 camp" can do distributable app-shemas, fine. It is odd though that they
currently don't except at laboratory level. The "XML camp" do this in production. Today.
Anders
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20105 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 11:04:06 -0800 (PST)
Received: from [128.33.238.47] (TC071.BBN.COM [128.33.238.71]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id OAA10655; Wed, 15 Nov 2000 14:11:31 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v0422080eb6388ac81acf@[128.33.238.47]>
In-Reply-To: <4.3.2.7.2.20001113163606.01a23e58@mail.spyrus.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <4.3.2.7.2.20001113163606.01a23e58@mail.spyrus.com>
Date: Wed, 15 Nov 2000 13:50:49 -0500
To: Russ Housley <housley@spyrus.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well
Cc: ietf-pkix@imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Russ,
>Steve:
>
>I agree with both of your points. However, XML-enabled clients are
>of interest when those clients are using XML digital signatures.
>
>I would like to see a solution where clients that are prepared to
>deal with ASN.1 can get a signed response in the CMS format (RFC
>2630), and clients that are prepared to deal with Signed XML can get
>a response in that yet-to-be-finalized format.
>Further, the XML client should be able to treat the X.509
>certificate as an octet blob. They simply pass the certificate to
>the trusted server, and the server returns a signed testament that
>the certificate is valid, the public key, and alt names. There may
>be other fields that should be returned, but we need to explore this
>model further to understand what they might be.
>
That seems reasonable based on your examples, but how do you want to
translate this into a standards requirement? If we made support for
ASN.1 or XML formats mandatory and the other optional it would
disadvantage one class of clients or the other. We can have two
distinct standards and let vendors choose which one to support, but
do we do that for both clients and servers, or do we plave the burden
on servers to support both forms of requests and to generate both
forms of responses?
Steve
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18067 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 10:19:46 -0800 (PST)
Received: from [128.33.238.47] (TC047.BBN.COM [128.33.238.47]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id NAA28301; Wed, 15 Nov 2000 13:27:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04220804b6387bd1941e@[128.33.238.44]>
In-Reply-To: <007301c04ee9$360fde50$0201a8c0@vincent.se>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]> <006701c04e5e$4891f030$0201a8c0@vincent.se> <007301c04ee9$360fde50$0201a8c0@vincent.se>
Date: Wed, 15 Nov 2000 12:45:05 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well?
Cc: <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Anders,
If your goal is to create a competing technology serving the same
function as ACs, but based exclusively on XML, then I think it might
be appropriate to create a new WG. Contact the Security ADs.
Steve
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18041 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 10:19:43 -0800 (PST)
Received: from [128.33.238.47] (TC047.BBN.COM [128.33.238.47]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id NAA28273; Wed, 15 Nov 2000 13:27:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04220803b6387a794320@[128.33.238.44]>
In-Reply-To: <005201c04ee0$9a2b8c80$0201a8c0@vincent.se>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]> <006701c04e5e$4891f030$0201a8c0@vincent.se> <v0422080fb637aa9c4f99@[171.78.30.108]> <005201c04ee0$9a2b8c80$0201a8c0@vincent.se>
Date: Wed, 15 Nov 2000 12:42:51 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
Cc: <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Anders,
>Steve,
>
>----- Original Message -----
>From: "Stephen Kent" <kent@bbn.com>
>To: "Anders Rundgren" <anders.rundgren@telia.com>
>Cc: <ietf-pkix@imc.org>
>Sent: Wednesday, November 15, 2000 03:56
>Subject: Re: Should PKIX protocols support XML well
>
> > >That an AC-app using "my" scheme would reject anything that does not
> > >*exactly* match a
> > >(usually very limited) set of known AC-app-specific schemas is *by
> > >design*. I.e. there is no
> > >(will not be is probably more correct), such thing as a generic AC
> > >application.
> >
> > This does nothing to protect against intentional attacks, since such
> > attackers are presumed capable of matching the syntax on per
> > application basis, although it might help with accidental "attacks."
>
>Using an XML schema you know when you are going to act on received data that:
>- The elements that the app "knows" are there. No more, no less
>- The elements have the proper format. I.e. no a 100k strings if
>the schema says 80
This is also enforced by ASN.1 compiler-generated structure decoding
code, so there's no feature difference here.
>And you get this for free. No coding whatsoever.
No coding other than the DTD/schema defintion, I presume, which is
equivalent to writing the ASN.1 syntax definition.
>That ought to be *more* secure than trying to "decipher" potentially
>arbitrary ASN.1 extensions.
One does not "try to decipher" extensions. Either one knows the
extension syntax, or one does not, and the extension is uniquely
identified bu=y an OID. If one does not know the OID, one skips the
extension. If one does know the syntax, the ASN.1 code decodes the
extension, and if there is a syntax error, i.e., if the data does not
match the syntactic definition, the decoding routine returns an
indication of the error.
>To add executable script code to XML would indeed introduce a
>security hole, but why
>would you do that in the context of ACs?
I think you misunderstood my analogy. Never mind.
Steve
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16687 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 10:01:10 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA08220; Wed, 15 Nov 2000 10:04:49 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <WZAJ3484>; Wed, 15 Nov 2000 10:08:39 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B5A3@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Denis Pinkas <Denis.Pinkas@bull.net>, Michael Myers <MMyers@verisign.com>
Cc: ietf-pkix@imc.org
Subject: RE: DPV vs SCVP
Date: Wed, 15 Nov 2000 10:08:32 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Denis,
Thanks for your in-depth review and comments on OCSPv2, both here and in
your off-list communications. To my reading, you have four points:
Replace "good" with "not revoked"
---------------------------------
The last call for comments on the I-D that led to RFC2560 occurred roughly
two years ago.
Replace "unknown" with "revocation status unknown"
--------------------------------------------------
See above.
It should not be manadatory to implement revocation status.
-----------------------------------------------------------
RFC2560 asserts that servers SHALL implement revocation status. In other
words, "shall be capable of" in order to ensure a minimum level of
interoperability across the Internet. It does not however require
deployment or activation of this functionality. Does this clarification
satisfy your concern?
An alternative ASN.1 syntax that preserves compatibility.
------------------------------------------------------------
This one is worth some discussion on the list since it's at the core of what
OCSPv2 is all about. The syntax that the OCSPv2 I-D proposes equally
intends to address backwards interoperability concerns. It was informed by
the approach CMS took in addressing the same issue. May I assume Denis that
you have no issue with the I-D's version number treatment?
Maybe the ASN.1 wizards out there could lend a hand here. For ease of
analysis, we have:
OCSPv2 -00 draft:
-----------------
Request ::= SEQUENCE {
reqCert ReqCert,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
ReqCert ::= CHOICE {
certID CertID,
issuerSerial [0] IssuerandSerialNumber,
pKCert [1] Certificate,
name [2] GeneralName }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
Version ::= INTEGER { v1(0), v2(1) }
"If certID is used in ReqCert, the version number used SHALL be v1. If
any
other identifier is used, the version number used SHALL be v2."
Denis proposes:
---------------
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber,
certHash OCTET STRING OPTIONAL,
pKCert Certificate OPTIONAL }
while, for completeness, RFC2560 states:
-----------------------------------------
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
The certHash option could be useful. We chose not to include it to minimize
complexity. We included a GeneralName option for environments that are best
enabled to PKI via Web-based naming schemes. Given those observations, it
seems that we have either six or half a dozen. It's still not clear to me
how your alternative formulation improves backwards interoperability beyond
that already proposed. Or am I overlooking something? Because I'm
otherwise strongly inclined to leave things as they are.
Mike
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16486 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 09:59:05 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA25892; Thu, 16 Nov 2000 07:05:35 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97431154424428>; Thu, 16 Nov 2000 07:05:44 (NZDT)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: John_Wray@iris.com, anders.rundgren@telia.com
Subject: Re: Should PKIX protocols support XML well?
Cc: ietf-pkix@imc.org
Sender: pgut001@cs.auckland.ac.nz
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 16 Nov 2000 07:05:44 (NZDT)
Message-ID: <97431154424428@kahu.cs.auckland.ac.nz>
John_Wray@iris.com writes:
>When building the Jonah freeware we put together an ASN.1 class library that
>supports almost all of the features you claim as intrinsic virtues of XML:
I'll add my $0.06 (the NZ$ isn't worth a lot at the moment) to this as well...
>>- Immediately recognize the message type by its schema name as found
>> by the parser. You could even dispatch the parsed message to
>> various apps directly based on found message type!
>> Schema=>Application=>Implict semantics.
>The Jonah library can do that (recognize a message type either implicitly by
>its structure or explicitly by an embedded tag).
My code does the same, throw any PKI-related object at it and it'll recognise
it automatically and process it as appropriate.
>>- Have the parser automatically check that all expected elements are
>> there (no more, no less), and fully conform to their format and
>> possible restrictions (i.e. not 100K UserIDs etc.) Supporting
>> standardized diagnostics like: "Address" field too long.
>> Missing "Session ID" tag etc.
>The Jonah ASN.1 library doesn't do much checking of restrictions, but that was
>an implementation choice rather than something imposed upon us by ASN.1.
Doing strict checking is a downside, not a feature. In my code I originally
did strict checking for compliance to RFC 2459, but found that there were so
many certs which fail the checks that I probably spent more time adding
special-case code to handle exceptions than in writing the cert-parsing code (I
remember posting a rant to this list some time ago where I noted that of 11
certs grabbed off the net, 10 failed to verify using the RFC 2459
requirements). Even now I'm still finding lots of certs from newly-appearing
CAs which don't comply with RFC 2459. When you distribute this per-cert
failure rate over entire chains, the one thing which checking that each cert
"fully conform[s] to their format and possible restrictions" will do is result
in about 90% of cert chains not verifying any more. In the end you have two
choices, perform strict checking and have your code (in the eyes of the user)
fail for large numbers of certs, or accept any old rubbish and have it appear
to work. I know which any company with commercial considerations will choose.
>>- Have "wizards" generate access class objects directly from the XML
>> app-schema if you want.
>Jonah doesn't have wizards; instead you simply declare a C++ class of the
>appropriate type directly from the ASN.1 syntax definition.
I have something similar, except that you use a simple notation based on the
ASN.1 syntax. In fact I would imagine that every implementation uses some sort
of automated generation process, I can't imagine anyone is still hand-coding
ASN.1.
>The above isn't intended as a plug for the Jonah code; It's simply an
>existence proof that the advantages you claim for XML are also achievable by
>ASN.1 (and in freeware too).
Ditto. Although it's cool to claim that XML invented all of this, it was being
done decades before anyone had ever heard of XML (in EDI/X.12/etc - maybe we
should all use EDI for this if the features touted for XML are so wonderful).
This stuff is hardly rocket science, just because XML is what they're wearing
in Paris this year doesn't mean we should throw away years of experience and
implementation work to chase the latest fad which comes along.
Peter.
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15534 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 08:47:51 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08009; Wed, 15 Nov 2000 08:55:12 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA00976; Wed, 15 Nov 2000 10:54:40 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA00916; Wed, 15 Nov 2000 10:54:40 -0500 (EST)
Message-ID: <3A12B13D.2BFBAD78@sun.com>
Date: Wed, 15 Nov 2000 10:52:29 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: stephen.farrell@baltimore.ie
CC: ietf-pkix@imc.org
Subject: Re: Cross-organizational ACs
References: <sa10f961.033@prv-mail20.provo.novell.com> <3A11BAAC.4140F4EF@sun.com> <3A126549.D617698A@baltimore.ie> <3A12AA3C.6F771B38@sun.com> <3A12AF55.279C2779@baltimore.ie>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Stephen Farrell wrote:
> > So I suggest that we omit AAControls from ac509prof.
> > It adds substantial complexity with little value.
>
> It doesn't add any complexity since its in the "optional
> to implement" section, just like attribute encryption. So,
> if you want to, do it, if not, not. I think this was the
> concensus of the WG at a number of meetings and on the
> list discussion on the various revs of the I-D.
It adds complexity to the spec. This makes it more difficult for
implementers to decide what to implement. And, if they decide to
implement this optional feature, it adds complexity to their
implementation. It also makes it more difficult for customers to decide
which features they need (since they will probably consult the RFC for
guidance). IETF specs (especially a profile!) should be as simple as
possible, but no simpler.
I just wanted to point out that AAControls is not sufficient for
cross-organizational ACs. If the consensus of the working group remains
to be that the AAControls extension is still valuable, I will certainly
accept this judgement. If there is a sudden flurry of emails saying
"take it out," that's fine with me, too. In either case, I will not
implement AAControls myself. And I will work on and think about a
simplified version of X.509 delegation that could be included in a
future AC profile.
-Steve
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10229 for <ietf-pkix@Imc.org>; Wed, 15 Nov 2000 08:11:22 -0800 (PST)
Received: from [128.33.238.44] (TC044.BBN.COM [128.33.238.44]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id LAA24454 for <ietf-pkix@Imc.org>; Wed, 15 Nov 2000 11:18:50 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v04220803b6386601099f@[128.33.238.44]>
In-Reply-To: <D44EACB40164D311BEF00090274EDCCAD59B22@sydneymail1.jp.zergo.com.au>
References: <D44EACB40164D311BEF00090274EDCCAD59B22@sydneymail1.jp.zergo.com.au>
Date: Wed, 15 Nov 2000 11:16:31 -0500
To: ietf-pkix@Imc.org
From: Stephen Kent <kent@bbn.com>
Subject: RE: OCSP-X vs SCVP
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Several folks sent me private messages agreeing that Juan's comments
were offensive, but worrying that my private message to Juan (which
he then sent to the PKIX list) was some sort of banishment. Let me
clarify:
I cannot and would not ban Jaun from attending a PKIX meeting. That
is clearly not appropriate, nor would it be allowed by IETF
procedures, to the best of my knowledge.
I meant exactly what I said, i.e., I look forward to not seeing Jaun
at these meetings. I also look forward to not seeing several other
folks who participate in various working groups, but sometimes I am
disappointed and I do see them at these meetings.
Steve
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09333 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 07:59:09 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16585; Wed, 15 Nov 2000 09:06:31 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA19952; Wed, 15 Nov 2000 11:06:30 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA02056; Wed, 15 Nov 2000 11:06:30 -0500 (EST)
Message-ID: <3A12B403.2165EE5B@sun.com>
Date: Wed, 15 Nov 2000 11:04:19 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: ietf-pkix@imc.org
Subject: Re: Cross-organizational ACs
References: <sa10f961.033@prv-mail20.provo.novell.com> <3A11BAAC.4140F4EF@sun.com> <00e501c04ef2$e033b0b0$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote:
> Bob and I seem to agree that this limitation makes PULL fairly
> "boring" (my wording)
Boring to you, perhaps. Many people would be glad to have a uniform
authorization system for multiple applications, even if it was
server-side only.
> E-mail clients as verifiers are a real PITA. When I open
> PKIX-messages from some people (who apparently run their own CAs) I
> constantly get alert messages due to unknown CA etc.
Your email client should be configured to inform you in a more
unobtrusive fashion that a signature could not be verified. Such
failures are an inevitable result of the chaotic nature of email and PKI
trust models, but most of the time you probably don't care.
> I.e. ACs would make the burden worse, but the problem is really built
> into PKI itself.
>
> IMO e-mail clients need SCVP or similar to get an almost
> "user-friendly" PKI.
I doubt that ACs or SCVP will change things much. You'll still have many
signatures that can not be verified. You may also have clearance
attributes that could not be verified and certificate status issues
(certificates whose revocation status could not be determined).
> Personally I see little point in S/MIME using ACs except maybe for
> server-based apps where the trust configuration stuff becomes much
> more manageble.
Agreed. Most users probably won't need ACs with S/MIME. For military
applications, it may be important.
> > If we were using delegation (a la X.509 2000), this could be handled
> > by domination rules. At the risk of opening a huge can of worms,
> > I'll inquire why we're creating our own delegation system (AA CAs)
> > instead of profiling the system provided by X.509.
>
> This is something I dont know about. Any pointers to "free"
> documents?
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV6.doc
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV6.pdf
-Steve
Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05672 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 07:33:08 -0800 (PST)
Received: by balinese.baltimore.ie; id PAA13114; Wed, 15 Nov 2000 15:40:37 GMT
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma012986; Wed, 15 Nov 00 15:39:56 GMT
Received: from baltimore.ie (ip203-221.ie.baltimore.com [192.168.21.203]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA32586; Wed, 15 Nov 2000 15:40:28 GMT
Message-ID: <3A12AF55.279C2779@baltimore.ie>
Date: Wed, 15 Nov 2000 15:44:21 +0000
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Hanna <steve.hanna@sun.com>
CC: ietf-pkix@imc.org
Subject: Re: Cross-organizational ACs
References: <sa10f961.033@prv-mail20.provo.novell.com> <3A11BAAC.4140F4EF@sun.com> <3A126549.D617698A@baltimore.ie> <3A12AA3C.6F771B38@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi Steve,
> So I suggest that we omit AAControls from ac509prof.
> It adds substantial complexity with little value.
It doesn't add any complexity since its in the "optional
to implement" section, just like attribute encryption. So,
if you want to, do it, if not, not. I think this was the
concensus of the WG at a number of meetings and on the
list discussion on the various revs of the I-D.
Stephen.
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane, fax: +353 1 647 7499
Dublin 2. mailto:stephen.farrell@baltimore.ie
Ireland http://www.baltimore.com
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02835 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 07:19:38 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G4200A01O98OO@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 15 Nov 2000 07:27:08 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G42009J1O97KN@ext-mail.valicert.com>; Wed, 15 Nov 2000 07:27:07 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NLTSP>; Wed, 15 Nov 2000 07:25:05 -0800
Content-return: allowed
Date: Wed, 15 Nov 2000 07:25:00 -0800
From: Frank Balluffi <frankb@valicert.com>
Subject: RE: OCSP-X vs SCVP
To: "'phil.griffin@asn-1.com'" <phil.griffin@asn-1.com>, rsalz@CaveoSystems.com
Cc: ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E136631@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Phil,
It might be useful to be able to control the level of "opaqueness". For
example, a certification path validation protocol might want to include XML
extensions in its requests and responses, but treat certificates, CRLs and
OCSP responses (which may also include extensions) as "opaque" DER-encoded
elements.
Frank
> -----Original Message-----
> From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com]
> Sent: Sunday, November 12, 2000 12:46 AM
> To: rsalz@CaveoSystems.com
> Cc: ietf-pkix@imc.org
> Subject: Re: OCSP-X vs SCVP
>
>
>
> >
> > Certainly ASN.1 is older and parts are more stable, but
> it's also growing
> > (and has grown -- PKIX1Explicit88, e.g.). So is XMLSchema. For the
> > purposes of comparison, let's just call them equivalent.
>
> But they are not. And you misunderstand. The module
> PKIX1Explicit88 is not itself ASN.1. It is one module
> of one specification written using ASN.1. It is a
> collection of definitions based on ASN.1 types. The
> values of these types conform to both the structure
> and rules for values defined by the ASN.1 standards.
>
> >
> > >If there were but one XML schema life would
> > >be easy. But there are many XML schema, and
> > >more seem to be popping up in various XML
> > >communities.
> >
> > That makes no more sense than saying there should be but
> one ASN.1 module.
>
> No. An ASN.1 module is not a schema.
>
> But ASN.1 can provide a schema for markup values
> that are associated with ASN.1 type definitions.
> This association makes it possible for ASN.1
> applications to transfer values to and from XML
> applications in a standard way. So ASN.1 can be
> used to define another set of rules, like BizTalk,
> DT4-DTD or XML-schema, for what constitutes valid
> typed values. Markup is just another way to
> represent these values.
>
> >
> > I'm not advocating that the IETF, the Security Area or the
> PKIX WG "use"
> > XML (for some definition of use). I am trying to show that the XML
> > communities are working to define *everything* needed to
> describe and
> > exchange data. It might not make sense to use it -- I personally
> > see little point in rewriting X.509v3 datatypes in XML-Schema -- but
> > we should be aware of what's going on for if/when we do
> decide to work
> > in that space.
> > /r$
>
> Agreed. What I am proposing is to modify the ASN.1
> standards so that the values of all ASN.1 types can
> be expressed using a common XML markup.
>
> So that for an arbitrary type definition, say
>
> MyType ::= SEQUENCE {
> label PrintableString,
> value INTEGER
> }
>
> a value of that type can be decoded by a recipient (or
> encoded and transferred by a sender) using the markup
>
> <MyType>
> <label>
> </label>
> <value>
> </value>
> </MyType>
>
> And so that a valid value of that ASN.1 type, a value
> which conforms to the rules defined in the ASN.1
> standards, such as
>
> userValue MyType ::= {
> label "My shoe size is ",
> value 10
> }
>
> can be encoded and transferred as either ASN.1
> encoded binary data or as the markup value
>
> <MyType>
> <label>
> My shoe size is
> </label>
> <value>
> 10
> </value>
> </MyType>
>
> This will provide a means to extend the capability
> deployed today - the ability to unambiguously encode
> and decode a value of an ASN.1 type. A standard markup
> for the ASN.1 notation will provide a new format for
> expressing the same ASN.1 values.
>
> By binding a standard markup to the values defined as
> valid for ASN.1 types, it will be possible for an ASN.1
> application to send or receive ASN.1 values in either
> text or binary formats.
>
> Phil
> ----
> Phillip H. Griffin Griffin Consulting
> http://asn-1.com Secure ASN.1 Design & Implementation
> +1-919-832-7008 1625 Glenwood Avenue, Five Points
> +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA
> ------------------------------------------------------------
>
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02286 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 07:17:43 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01375; Wed, 15 Nov 2000 07:25:02 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA24213; Wed, 15 Nov 2000 10:24:47 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA28341; Wed, 15 Nov 2000 10:24:46 -0500 (EST)
Message-ID: <3A12AA3C.6F771B38@sun.com>
Date: Wed, 15 Nov 2000 10:22:36 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: stephen.farrell@baltimore.ie
CC: ietf-pkix@imc.org
Subject: Re: Cross-organizational ACs
References: <sa10f961.033@prv-mail20.provo.novell.com> <3A11BAAC.4140F4EF@sun.com> <3A126549.D617698A@baltimore.ie>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Stephen Farrell wrote:
> Your summary is correct. The reason for the text being as it is now
> is that the X.509 (2000) delegation model was felt to be much too
> complex for an initial PKIX profile. AAControls was provided as
> an attempt to provide some of the controls required in a simple
> way.
Unfortunately, AAControls does not provide the constraints that most
organizations will need in order to recognize ACs from other
organizations (constraints on attribute values, not just attribute
types).
Given this limitation, why keep AAControls at all? Wouldn't it be better
to work on simplifying and profiling X.509 delegation for some future
PKIX AC profile than to create a less functional duplicate system now
and have to support it in the future?
It is true that AAControls allows AC verifiers to recognize multiple AC
issuers with only a single configured AA CA. But the crude nature of the
constraints included in AAControls mean that all the AC issuers must be
within a single trust domain (unless the crude constraints are
sufficient, which isn't likely in my view). I don't think this feature
is very valuable. So I suggest that we omit AAControls from ac509prof.
It adds substantial complexity with little value.
> So lets not open up the delegation can of worms, until someone
> steps up with a simple, working solution for delegation of X.509
> ACs.
Agreed. Let's set aside delegation for now (at least in this forum). ACs
have many uses that do not require delegation.
-Steve
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02174 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 07:16:44 -0800 (PST)
Received: from mega (t1o69p4.telia.com [62.20.144.4]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id QAA29834; Wed, 15 Nov 2000 16:24:00 +0100 (CET)
Message-ID: <017401c04f17$e31489b0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: <John_Wray@iris.com>
Cc: <ietf-pkix@imc.org>
References: <OF3F0B554A.7AC49777-ON85256998.004CF71A@iris.com>
Subject: Re: Should PKIX protocols support XML well?
Date: Wed, 15 Nov 2000 16:22:37 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA02175
John,
<snip>
> >- Let each "application profile" have it own schema. As in BizTalk.
> > And let applications evolve in their own pace. Much simplier (and
> > futureproof) than trying to squeeze in things like it is done in AC.
>
> Since defining a parser for a new syntax is a trivial process, a simple
> extension mechanism works fine for this.
If you take the current AC draft which was the basis for this thread,
I would like to know how you specify and create code for something which
is outside the specification. And how do you transmit the extenson information?
As ASN.1 source? OK, that technically *works* but I doubt that this will
get any major backing (unlike XML).
And it is not as elegant as app-specific XML schemas.
Anders
Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28496 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 06:41:24 -0800 (PST)
From: John_Wray@iris.com
Subject: Re: Should PKIX protocols support XML well?
To: "Anders Rundgren" <anders.rundgren@telia.com>
Cc: <ietf-pkix@imc.org>
X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000
Message-ID: <OF3F0B554A.7AC49777-ON85256998.004CF71A@iris.com>
Date: Wed, 15 Nov 2000 09:49:23 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/15/2000 09:53:09 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Anders,
When building the Jonah freeware we put together an ASN.1 class library
that supports almost all of the features you claim as intrinsic virtues of
XML:
>- Immediately recognize the message type by its schema name as found
> by the parser. You could even dispatch the parsed message to
> various apps directly based on found message type!
> Schema=>Application=>Implict semantics.
The Jonah library can do that (recognize a message type either implicitly
by its structure or explicitly by an embedded tag).
>- Have the parser automatically check that all expected elements are
> there (no more, no less), and fully conform to their format and
> possible restrictions (i.e. not 100K UserIDs etc.) Supporting
> standardized diagnostics like: "Address" field too long.
> Missing "Session ID" tag etc.
The Jonah ASN.1 library doesn't do much checking of restrictions, but that
was an implementation choice rather than something imposed upon us by
ASN.1. ASN.1 allows such restrictions to be expressed; we simply chose to
enforce them above the parser library. It will certainly detect missing
fields.
>- Let each "application profile" have it own schema. As in BizTalk.
> And let applications evolve in their own pace. Much simplier (and
> futureproof) than trying to squeeze in things like it is done in AC.
Since defining a parser for a new syntax is a trivial process, a simple
extension mechanism works fine for this.
>- Have "wizards" generate access class objects directly from the XML
> app-schema if you want. Click on the fields of interest and you are
> there! That is a quantum leap above trying to decode arbitrary
> extension at application level (well, to be honest, I am pretty
> old-fashioned and seldom use wizards but all "new" people seem
> very thrilled by such tools...).
Jonah doesn't have wizards; instead you simply declare a C++ class of the
appropriate type directly from the ASN.1 syntax definition. You don't have
to write any code, just a C++ header file containing class definitions (you
may have to write a simple constructor for composite objects, but that's by
rote, and is the full extent of any programming required).
I don't understand what this has to do with "decoding arbitrary extensions
at the application level"; For X.509 certificates, Jonah simply declares
parsers for each extension type and applies the appropriate parser to an
extension based on the extension's extnId value.
>- Let you [automatically] verify that your output conforms to the spec.
Just to be a nice guy.
That's automatic with the Jonah library - once you've declared a parser
class, that class is also used if you want to generate ASN.1 DER that
conforms to the same syntax. There's no "verification" step - the class
just generates appropriate DER.
The above isn't intended as a plug for the Jonah code; It's simply an
existence proof that the advantages you claim for XML are also achievable
by ASN.1 (and in freeware too).
John
"Anders Rundgren" <anders.rundgren@telia.com> on 11/15/2000 04:48:29 AM
To: <ietf-pkix@imc.org>
cc:
Subject: Re: Should PKIX protocols support XML well?
This conversion of things to XML from ASN.1 is IMO not that interesting as
XML in itself
(except for being "trendy", "free", and "human readable") does not offer
any advantages
over ASN.1. Rather adds som disadvantages like bloated size.
It is sad, some XML "marketers" even claim that XML solves semantics as
well (using "magic"),
but they are dead wrong!
But if you use XML *schemas* you could also:
- Immediately recognize the message type by its schema name as found by the
parser. You could
even dispatch the parsed message to various apps directly based on found
message type!
Schema=>Application=>Implict semantics.
- Have the parser automatically check that all expected elements are there
(no more, no less), and
fully conform to their format and possible restrictions (i.e. not 100K
UserIDs etc.) Supporting standardized
diagnostics like: "Address" field too long. Missing "Session ID" tag etc.
- Let each "application profile" have it own schema. As in BizTalk. And
let applications evolve in
their own pace. Much simplier (and futureproof) than trying to squeeze in
things like it is done in AC.
- Have "wizards" generate access class objects directly from the XML
app-schema if you want. Click
on the fields of interest and you are there! That is a quantum leap above
trying to decode arbitrary
extension at application level (well, to be honest, I am pretty
old-fashioned and seldom use wizards but all
"new" people seem very thrilled by such tools...).
- Let you [automatically] verify that your output conforms to the spec.
Just to be a nice guy.
So IMO, ACs and similar which I consider very application-specific (*not*
PKCs), would benefit
tremendously by being split into a header document and an application
document using schemas
to avoid extensions and app-level parsing completely.
Unfortunately the XML schema route does not have an ASN.1 counterpart. A
truly one-way-street.
Off-list I have been adviced to start a new WG to avoid these time-wasting
ASN.1 - XML wars.
Is that maybe the general feeling? How do I proceed?
Regards
Anders Rundgren
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26857 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 06:13:27 -0800 (PST)
Received: from mega (t1o69p41.telia.com [62.20.144.41]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id PAA09460; Wed, 15 Nov 2000 15:20:51 +0100 (CET)
Message-ID: <015901c04f0f$10ec76d0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: <torrent@acm.org>, "Stephen Kent" <kent@bbn.com>
Cc: "'Ietf-Pkix@Imc. Org '" <ietf-pkix@imc.org>
References: <NDBBJKCNGLOIIBOHCOLHGEJJCEAA.jrtorrent@earthlink.net>
Subject: XML War! Where is the battleground?
Date: Wed, 15 Nov 2000 15:19:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA26861
OK guys!
Calm down!
Couldn't we make this XML vs.ASN.1 -thing the #1 San Diego PKIX item
or is it too late?
Or Steve, should we simply start a new WG?
/anders
----- Original Message -----
From: "Juan Rodriguez-Torrent" <jrtorrent@earthlink.net>
To: "Stephen Kent" <kent@bbn.com>
Cc: "'Ietf-Pkix@Imc. Org '" <ietf-pkix@imc.org>
Sent: Wednesday, November 15, 2000 06:01
Subject: RE: OCSP-X vs SCVP
> Steve, I'm sorry that you felt personally attacked. At the time I wrote the
> note you find offensive, that was far from my mind and definitively not my
> intention. You and I have had disagreements on and off for a few years but I
> had too much respect for you to let philosophical differences become
> personal. The second statement in your note is stunning coming from someone
> of your stature.
>
> Juan Rodriguez-Torrent, CTO
> Aposematic Corporation
>
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Tuesday, November 14, 2000 12:13 PM
> To: torrent@acm.org
> Subject: RE: OCSP-X vs SCVP
>
> Juan,
>
> I found your comments on the topic offensive.
>
> Hope to not see you at the next IETF meeting.
>
> Steve
>
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA23314 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 04:40:26 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA65350; Wed, 15 Nov 2000 13:53:48 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id NAA18318; Wed, 15 Nov 2000 13:47:26 +0100
Message-ID: <3A1285E1.857CB62D@bull.net>
Date: Wed, 15 Nov 2000 13:47:29 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <MMyers@verisign.com>
CC: ietf-pkix@imc.org
Subject: Re: DPV vs SCVP
References: <2F3EC696EAEED311BB2D009027C3F4F4017CE6A8@vhqpostal.verisign.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mike,
A few, but important comments on this E-mail sent last week.
> Russ, thanks for getting this debate kicked off. After all the work various
> of us have put into this issue, I was beginning to think no one cared.
>
> All, as to the debate:
>
> Let's hear from everybody before we make a decision.
> ----------------------------------------------------
> Thanks to all who have read the IDs and provided comments (especially Denis
> Pinkas). But since active WG members have taken time out of their busy
> schedules to improve the IDs, I think it only fair that final judgement be
> witheld until those contributions are folded into a revised version for our
> consideration in San Diego. At that time it might be more appropriate to
> decide between the two.
>
> It's DPV vs. SCVP
> -----------------
> OCSP-X has expired; DPV and DPD replace that initial work. The requirement
> we're all most concerned about is delegated path validation (although
> delegated path discovery has it's use). So it really comes down to DPV+DPD
> vs. SCVP since OCSP is already RFC 2560. DPV is little more than an OID and
> a corresponding semantic; it simply puts more meat behind 2560's notion of
> "good".
I disagree with this last statement. Extensions allows to request new
services. The request for each every new service may fail or succeed. This
means that each extension will have to carry the result of the request for
the new service. This also means that the current status will only carry the
response to a *status revocation request*, but will not carry any additional
meaning. "Good" is not the appropriate term to be used: "not revoked" is the
right term and should be used instead, when we revised OCSP.
> DPD is only a bit more along these same lines of design.
>
> They're going to do it anyway.
> ------------------------------
> DPV and DPD are nothing more than proposed standard extensions to the
> already existing extension hooks in 2560. Given the availablility of those
> hooks, there's nothing to stop any environment from doing precisely this, if
> only to establish a closed system-level solution. Given that, it's better
> that we take responsible action to promote Internet interoperability via a
> standard means of doing so in the event that such closed environments may
> someday find it useful to interoperate.
The real advantage to add DPV and DPD to OCSP is to be able to support both
a revocation status request and DPV or DPV+DPD in a single request. It
should however be noticed that a response to a status revocation request is
not mandatory since the server may well return a "revocation status unknown"
response, but still respond to a DPD (Delegated Path Discovery) for the
certificate.
> OCSPv2 is separable to the DPV vs. SCVP question
> ------------------------------------------------
> Carlisle, Rich Ankney and I separately proposed OCSPv2. At its core, this
> is simply an expansion of certificate identification syntax to accomodate
> well-known use cases of the existing RFC 2560. It's really nothing more
> than:
>
> ReqCert ::= CHOICE {
> certID CertID,
> issuerSerial [0] IssuerandSerialNumber,
> pKCert [1] Certificate,
> name [2] GeneralName }
>
> where in 2560 we simply have:
>
> CertID ::= SEQUENCE {
> hashAlgorithm AlgorithmIdentifier,
> issuerNameHash OCTET STRING, -- Hash of Issuer's DN
> issuerKeyHash OCTET STRING, -- Hash of Issuers public key
> serialNumber CertificateSerialNumber }
I am not convinced it is the right way to do, because we loose backward
compatibily with OCSP v1. I have sent privately a proposal to you and the
co-editors where compatibility can be preserved, and where more syntax
options can be supported without using ReqCert. Here it is:
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber,
certHash OCTET STRING OPTIONAL,
pKCert Certificate OPTIONAL }
> There's also a version number delta and corresponding guidance when to use a
> given version number.
>
> The lack of these alternatives is a long-standing criticism of 2560 and will
> be fixed regardless of the outcome of the DPV vs. SCVP debate. Again, many
> thanks to Denis Pinkas for his detailed, thoughtful and constructive
> commentary on the OCSPv2 ID. I'll be bringing this up in a totally separate
> thread from the DPV vs. SCVP discussion to resolve the MUSTs related to
> supporting these various identification schemes.
>
> XML is a whole new ballgame
> ---------------------------
> It's true that the OCSPv2, DPV and DPD IDs don't address XML. There are two
> reasons for this. First, there can be no doubt that XML can be an useful
> PKI delivery platform. Khaja Ahmed's recent analysis said it well. But
> there's probably going to be many competeting proposals addressing this
> need. Secondly, considering XML only in the context of delegated path
> validation ignores the full set of certificate lifecycle needs (e.g.
> enrollment, renewal and revocation) that must be met to fully deliver on the
> XML+PKI "vision".
>
> In sum, it's quite possible that XML-based status needs are better met by a
> tighter integration with business practices than is currently enabled by
> ASN.1 based solutions. We can however predict with a reliable degree of
> accuracy how an ASN.1-based solution integrates at least to existing
> PKI-related protocols. Hence the DPV/DPD proposals chose to define a very
> simple means by which a solution to these pressing certificate status needs
> can be met with maximal reuse of existing ASN.1 investments, leaving the way
> clear for XML+PKI to take its own course.
I have sent yesterday a message to Ambarish on that topic. I am awaiting for
his response.
Regards,
Denis
> Best regards to all,
>
> Mike
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14649 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 02:51:37 -0800 (PST)
Received: from mega (t6o69p35.telia.com [213.64.110.155]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id LAA28989; Wed, 15 Nov 2000 11:59:03 +0100 (CET)
Message-ID: <00e501c04ef2$e033b0b0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Steve Hanna" <steve.hanna@sun.com>, <ietf-pkix@imc.org>
References: <sa10f961.033@prv-mail20.provo.novell.com> <3A11BAAC.4140F4EF@sun.com>
Subject: Re: Cross-organizational ACs
Date: Wed, 15 Nov 2000 11:57:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA14651
Steve,
> However, I still think there are several unresolved issues with
> cross-organizational ACs (where the issuer and the verifier are in
> different organizations, especially with limited trust).
The major problem is IMO the lack of enthuseasm for the AC concept which
likely will leave it without TLS support. Another problem is the packaging (ASN.1)
which is inappropriate for ACs which are *application specific* to an extent that
few other PKIX objects are. The organizational issues (if not solved) just put the
final nail in the AC coffin.
> 1) As Anders pointed out, in the pull scenarios the AC verifier may not
> know where to get an AC issued by another organization. We could add
> a pointer in the PKC saying how to get ACs for the subject, but I
> suspect that won't work very well due to the political and technical
> issues raised by Bob Jueneman. In all likelihood, pull scenarios
> will only use ACs from the verifier's organization.
Bob and I seem to agree that this limitation makes PULL fairly "boring" (my wording)
> 2) With cross-organizational ACs, the AC verifier should not need to be
> configured with a complete list of trusted AC issuers. Otherwise,
> all AC verifiers will need to be updated whenever the list of
> trusted organizations changes. This would be especially bad with
> S/MIME, since each email client is an AC verifier.
E-mail clients as verifiers are a real PITA. When I open PKIX-messages from some
people (who apparently run their own CAs) I constantly get alert messages due to
unknown CA etc.
I.e. ACs would make the burden worse, but the problem is really built into PKI itself.
IMO e-mail clients need SCVP or similar to get an almost "user-friendly" PKI.
Personally I see little point in S/MIME using ACs except maybe for server-based
apps where the trust configuration stuff becomes much more manageble.
<snip>
> If we were using delegation (a la X.509 2000), this could be handled
> by domination rules. At the risk of opening a huge can of worms,
> I'll inquire why we're creating our own delegation system (AA CAs)
> instead of profiling the system provided by X.509.
This is something I dont know about. Any pointers to "free" documents?
Regards
Anders R
Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11210 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 02:17:06 -0800 (PST)
Received: by balinese.baltimore.ie; id KAA22343; Wed, 15 Nov 2000 10:24:34 GMT
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma022213; Wed, 15 Nov 00 10:24:01 GMT
Received: from baltimore.ie (ip203-221.ie.baltimore.com [192.168.21.203]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA21237; Wed, 15 Nov 2000 10:24:30 GMT
Message-ID: <3A126549.D617698A@baltimore.ie>
Date: Wed, 15 Nov 2000 10:28:25 +0000
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Hanna <steve.hanna@sun.com>
CC: ietf-pkix@imc.org
Subject: Re: Cross-organizational ACs
References: <sa10f961.033@prv-mail20.provo.novell.com> <3A11BAAC.4140F4EF@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi Steve,
Your summary is correct. The reason for the text being as it is now
is that the X.509 (2000) delegation model was felt to be much too
complex for an initial PKIX profile. AAControls was provided as
an attempt to provide some of the controls required in a simple
way.
So lets not open up the delegation can of worms, until someone
steps up with a simple, working solution for delegation of X.509
ACs.
Stephen.
> Unfortunately, I suspect that these constraints will not be
> sufficient for most organizations. For instance, one organization
> may trust another to issue ACs containing the Group attribute, but
> only for certain groups. Or they might trust them to issue ACs with
> the Clearance attribute, but not for the topSecret class.
>
> If we were using delegation (a la X.509 2000), this could be handled
> by domination rules. At the risk of opening a huge can of worms,
> I'll inquire why we're creating our own delegation system (AA CAs)
> instead of profiling the system provided by X.509.
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane, fax: +353 1 647 7499
Dublin 2. mailto:stephen.farrell@baltimore.ie
Ireland http://www.baltimore.com
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08732 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 01:42:24 -0800 (PST)
Received: from mega (t1o69p72.telia.com [62.20.144.72]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id KAA03291 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 10:49:53 +0100 (CET)
Message-ID: <007301c04ee9$360fde50$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]> <006701c04e5e$4891f030$0201a8c0@vincent.se>
Subject: Re: Should PKIX protocols support XML well?
Date: Wed, 15 Nov 2000 10:48:29 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA08733
This conversion of things to XML from ASN.1 is IMO not that interesting as XML in itself
(except for being "trendy", "free", and "human readable") does not offer any advantages
over ASN.1. Rather adds som disadvantages like bloated size.
It is sad, some XML "marketers" even claim that XML solves semantics as well (using "magic"),
but they are dead wrong!
But if you use XML *schemas* you could also:
- Immediately recognize the message type by its schema name as found by the parser. You could
even dispatch the parsed message to various apps directly based on found message type!
Schema=>Application=>Implict semantics.
- Have the parser automatically check that all expected elements are there (no more, no less), and
fully conform to their format and possible restrictions (i.e. not 100K UserIDs etc.) Supporting standardized
diagnostics like: "Address" field too long. Missing "Session ID" tag etc.
- Let each "application profile" have it own schema. As in BizTalk. And let applications evolve in
their own pace. Much simplier (and futureproof) than trying to squeeze in things like it is done in AC.
- Have "wizards" generate access class objects directly from the XML app-schema if you want. Click
on the fields of interest and you are there! That is a quantum leap above trying to decode arbitrary
extension at application level (well, to be honest, I am pretty old-fashioned and seldom use wizards but all
"new" people seem very thrilled by such tools...).
- Let you [automatically] verify that your output conforms to the spec. Just to be a nice guy.
So IMO, ACs and similar which I consider very application-specific (*not* PKCs), would benefit
tremendously by being split into a header document and an application document using schemas
to avoid extensions and app-level parsing completely.
Unfortunately the XML schema route does not have an ASN.1 counterpart. A truly one-way-street.
Off-list I have been adviced to start a new WG to avoid these time-wasting ASN.1 - XML wars.
Is that maybe the general feeling? How do I proceed?
Regards
Anders Rundgren
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA01035 for <ietf-pkix@imc.org>; Wed, 15 Nov 2000 00:40:49 -0800 (PST)
Received: from mega (t4o69p25.telia.com [62.20.145.145]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA13775; Wed, 15 Nov 2000 09:48:15 +0100 (CET)
Message-ID: <005201c04ee0$9a2b8c80$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>
Cc: <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]> <006701c04e5e$4891f030$0201a8c0@vincent.se> <v0422080fb637aa9c4f99@[171.78.30.108]>
Subject: Security with XML vs ASN.1. Was: Should PKIX protocols support XML well
Date: Wed, 15 Nov 2000 09:46:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA01039
Steve,
----- Original Message -----
From: "Stephen Kent" <kent@bbn.com>
To: "Anders Rundgren" <anders.rundgren@telia.com>
Cc: <ietf-pkix@imc.org>
Sent: Wednesday, November 15, 2000 03:56
Subject: Re: Should PKIX protocols support XML well
> >That an AC-app using "my" scheme would reject anything that does not
> >*exactly* match a
> >(usually very limited) set of known AC-app-specific schemas is *by
> >design*. I.e. there is no
> >(will not be is probably more correct), such thing as a generic AC
> >application.
>
> This does nothing to protect against intentional attacks, since such
> attackers are presumed capable of matching the syntax on per
> application basis, although it might help with accidental "attacks."
Using an XML schema you know when you are going to act on received data that:
- The elements that the app "knows" are there. No more, no less
- The elements have the proper format. I.e. no a 100k strings if the schema says 80
And you get this for free. No coding whatsoever.
That ought to be *more* secure than trying to "decipher" potentially arbitrary ASN.1 extensions.
To add executable script code to XML would indeed introduce a security hole, but why
would you do that in the context of ACs?
Anders
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09640 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 21:11:48 -0800 (PST)
Received: from [128.33.238.71] (TC071.BBN.COM [128.33.238.71]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id AAA11361; Wed, 15 Nov 2000 00:19:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04220801b637cd0bf742@[128.33.238.71]>
In-Reply-To: <NDBBJKCNGLOIIBOHCOLHGEJJCEAA.jrtorrent@earthlink.net>
References: <NDBBJKCNGLOIIBOHCOLHGEJJCEAA.jrtorrent@earthlink.net>
Date: Wed, 15 Nov 2000 00:19:59 -0500
To: <torrent@acm.org>
From: Stephen Kent <kent@bbn.com>
Subject: RE: OCSP-X vs SCVP
Cc: "'Ietf-Pkix@Imc. Org '" <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Juan,
Your forwarding of my private response to the list calls into
question the apologetic tone of your message, and reaffirms my lack
of enthusiasm for further, direct interaction.
Steve
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA09061 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 20:58:24 -0800 (PST)
Received: from [128.33.238.71] (TC071.BBN.COM [128.33.238.71]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id AAA09990; Wed, 15 Nov 2000 00:05:33 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v0422080fb637aa9c4f99@[171.78.30.108]>
In-Reply-To: <006701c04e5e$4891f030$0201a8c0@vincent.se>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]> <006701c04e5e$4891f030$0201a8c0@vincent.se>
Date: Tue, 14 Nov 2000 21:56:09 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well
Cc: <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Anders,
>Steve,
>
> >Although ACs are generally assumed to be more dynamic than PKCs,
>but different usage models
> >call for different validity intervals. Thus I don't agree that
>they are as message like as you suggest.
> >The XML-based schema you suggest would be more flexible, and
>arguably less interoperable.
>
>Here we apparently differ. IMO AC are potentially *extremely*
>application-dependent
>which makes interoperability an entirely different story than for PKCs.
We have traditionally use standard access control mechanisms in
operating systems to provide a basis for access controls for a
variety of applications. Having a consistent basis for AC helps
reduce design and implementation vulnerabilities. Our disagreement is
with regard to where the commonality ends. You suggest that a common
language (XML) suffices, while AC advocates argue for a common
language (ASN.1), syntax, and base semantics.
>
>That an AC-app using "my" scheme would reject anything that does not
>*exactly* match a
>(usually very limited) set of known AC-app-specific schemas is *by
>design*. I.e. there is no
>(will not be is probably more correct), such thing as a generic AC
>application.
This does nothing to protect against intentional attacks, since such
attackers are presumed capable of matching the syntax on per
application basis, although it might help with accidental "attacks."
>
>There can (and should) still be a framework but it should be split
>into a standardized part and
>one which is entirely application-defined. Then you can create a
>generic AC reader/verifier.
>
Again, it's a difference of opinion of where the common layer should terminate.
Steve
Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08845 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 20:53:47 -0800 (PST)
Received: from dad (dhcp090-2-151-24.nt01-c4.cpe.charter-ne.com [24.151.2.90]) by gull.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id VAA17940; Tue, 14 Nov 2000 21:01:05 -0800 (PST)
Reply-To: <torrent@acm.org>
From: "Juan Rodriguez-Torrent" <jrtorrent@earthlink.net>
To: "Stephen Kent" <kent@bbn.com>
Cc: "'Ietf-Pkix@Imc. Org '" <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Wed, 15 Nov 2000 00:01:13 -0500
Message-ID: <NDBBJKCNGLOIIBOHCOLHGEJJCEAA.jrtorrent@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <v0422080db637230243c3@[171.78.30.108]>
Steve, I'm sorry that you felt personally attacked. At the time I wrote the
note you find offensive, that was far from my mind and definitively not my
intention. You and I have had disagreements on and off for a few years but I
had too much respect for you to let philosophical differences become
personal. The second statement in your note is stunning coming from someone
of your stature.
Juan Rodriguez-Torrent, CTO
Aposematic Corporation
-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Tuesday, November 14, 2000 12:13 PM
To: torrent@acm.org
Subject: RE: OCSP-X vs SCVP
Juan,
I found your comments on the topic offensive.
Hope to not see you at the next IETF meeting.
Steve
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA21927 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 16:16:48 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 14 Nov 2000 17:23:39 -0700
Message-Id: <sa11751b.044@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 14 Nov 2000 17:23:36 -0700
From: "Bob Jueneman" <bjueneman@novell.com>
To: <mzolotarev@baltimore.com>, <marcnarc@xcert.com>
Cc: <ietf-pkix@imc.org>
Subject: Re: OCSP-X vs SCVP
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA21928
>
>But I see your point. You weren't talking about an OCSP API, but instead an
>ASN.1 (as opposed to XML) API. At that level, I agree: people can pick up
>toolkits to work with either.
>
>Many, though, seem to be reluctant to have to work with both. I suppose
>there this is where the crux of the issue lies. Most PKI folk work in ASN.1,
>while many non-PKI folk use XML. The non-PKI folk want their XML apps to use
>PKI (as do the PKI folks, I might add), but they don't want to bloat their
>apps with an ASN.1 toolkit. Similarly, the PKI folk don't want to bloat
>their apps with an XML toolkit.
>
>Either some non-PKI folk have to want PKI badly enough to accept the bloat,
>or the PKI folk have to want to spread PKI badly enough to adopt XML. Either
>way, someone has to give.
Just as a data point re the alleged "bloat" caused by ASN.1.
We wrote our own toolkit, and the core functionality is about 12K of code.
The full set with the frequently used set of OIDs, certificate prototypes, etc.,
maybe amounts to 20K+ .
So far, the overhead of statically binding a 20K toolkit is so low that we haven't
even bothered to turn this into a DLL (or the equivalent for other operating systems),
although it would be easy to do so.
As for non-vendors (high school students?) who don't have the time, money or inclination
to acquire commercial toolkits themselves, (a) let them eat cake? :-) or (b) let them
go to people like Peter Gutmann and/or other public domain sources.
The toolkit issue is a red herring, I believe. It is really more of a stylistic and/or
education or religious question, like debating the merits of C vs. CORBA..
As someone once said in a different context, arguing this point is like teaching
a pig to whistle. It is a waste of your time, and it annoys the pig.
Bob
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA21160 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 15:27:48 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 14 Nov 2000 16:34:30 -0700
Message-Id: <sa116996.005@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 14 Nov 2000 16:34:32 -0700
From: "Bob Jueneman" <bjueneman@novell.com>
To: <ietf-pkix@imc.org>, <dpkemp@missi.ncsc.mil>
Subject: Re: Extended Key Usage and path validation
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA21161
It occurs to me that this discussion is closely related to the attribute certificates discussion. Here's why.
I'm not sure exactly which particular Extended Key Usage usages are being discussed. Perhaps the intent is to be generic, and to include even proprietary EKUs, i.e., usages that may be quite useful, but haven't yet reach the point of critical mass to deserve standardization. But in general it appears that people are trying to use extended key usages to control what amount to privileges, i.e. the right to perform some certain action, or to be believed after such an action is performed
In any case, I believe that the real issue is delegation of control, or vice versa, control of delegation. My sense is that people are looking for a convenient, easily automated way of determining not only whether a given end entity is entitled to exercise a particular function (with respect to a specified key pair), but whether the CA (or AA) that issued that certificate was itself authorized to delegate that particular function to that end-entity.
The need for this type of delegation control mechanism is precisely why the hierarchical MAC label portion of the Novell Security Attributes (c.f. http://developer.novell.com/repository/attributes/certattrs_v10.htm ) was constructed the way it was -- as a set of security/integrity levels, and perhaps more importantly, as a set of arbitrary capability bits. By simply ANDing all of the capability bits of a given type together, from the root cert down to the end entity certificate, it is extremely easy to determine whether every certificate in the chain was duly authorized for that particular attribute.
More to the point, if the RP includes his own "meets minimum" criteria label in that chain of labels, the RP can deny the effective right of some entity to delegate a particular attribute, even if under ordinary circumstances the delegating agency would possess that right. For example, it is not unusual for two companies to be partners with respect to some particular business matter, and yet competitors with respect to some other matter. So depending on the context of a particular transaction, the RP might decide whether or not to trust a particular CA, sub-CA, or end entity -- not because of some flaw in the attribute authority itself, or in the end entity, but just because the RP chooses not to trust that particular attribute in that particular context.
Whether that particular right is expressed as an attribute certificate, or as an EKU, I believe that there will always be a requirement to be able to control the delegation of that attribute. Currently, attribute certificates accomplish that by making the RP exercise control over what root AAs are accepted -- an exceedingly blunt instrument in my view. On the other hand, if no controls are imposed on a CA who issues a certificate containing a particular EKU, then the only controls are legal/policy, and from a RP software point of view those are effectively unimplementable.
Finally, I do completely agree with the statement that Policy OIDs are NOT the way to accomplish this. Not only are such policy OIDs not standardized, but the multiplicity of them would significantly increase the size and complexity of the certificate itself, and of certificate path processing. I am quite confident of this, because when Dr. Roger Schell (the author of the original orange Book, and my boss at the time) were trying to design this mechanism, I had proposed on OID approach based on familiarity with the Policy OID. We had some rather heated discussions pro and con, until finally one Sunday afternoon, at the kitchen table at his house, he sketched the MAC label approach, and the light finally went on. Been there and done that, in other words.
Policy OIDs and Policy OID constraints, may have a role to play in enforcing closed PKI user agreements, in particular if the certificate is used in violation of the terms and conditions set down by the CA, or by some governing organization with respect to liability limitations, etc. (I say may, because I don't believe anyone has yet deployed a meaningful worked example of such constraints being enforced that would demonstrate that fact. But that is a different matter.)
But I am convinced that CP policies would be an absolutely lousy way to try to control the distributed delegation and validation of privileges or rights -- it is simply too hard to do the necessary computations and/or path processing to implement such a scheme in a reasonably efficient access control mechanism.
>>>> "David P. Kemp" <dpkemp@missi.ncsc.mil> 11/09/00 09:54AM >>>
>
>> From: thayes@netscape.com (Terry Hayes)
>>
>> A CA can put this global OID into the CertificatePolicies along with
>> OIDs for its own more specific or more constrained policies. The
>> extension can handle more than one OID.
>>
>> > [Patrick.Patterson@sita.int]
>> > I know the issue here is that we need some technical way to assure that a given
>> > certificate isn't used for something that it was not intended for, but I'm not
>> > sure that either the current method or your proposed fix is the way it should
>> > go. Shouldn't this be something that an attribute certificate be used for, or am
>> > I completely off the mark with that?
>
>
>I agree with Steve Kent that putting an EKU in a CA certificate which does
>not apply to the CA's key is a misusage of that extension.
Me, too.
>
>I agree with Patrick Patterson and Michael Ströder that using the
>Certificate Policies extension to control usage of the EE key
>"messes with" the CP extension. The policy under which certificates
>are issued seems tenuously related, if not completely unrelated,
>to the applications which make use of the certificates.
Exactly. They should be used sparingly for legal/policy mechanisms, not to control privileges. (AKA "key usages")
>
>We have basic constraints, name constraints, and policy constraints,
>all of which limit the capabilities of lower CAs and EEs. And PKIX has
>defined AIA and SIA private (non-X.509) extensions. If it really is
>necessary for a CA to constrain the usage of an End Entity's key,
>shouldn't we be defining a PKIX-private "EKU Constraints" extension to
>be placed in CA certificates?
>
>I'm not convinced that EKU serves a useful purpose. And if EKU itself
>is useful, I'm even less convinced that constraining it at the CA
>level, whatever the mechanism, is useful. If you want EKUs, and you
>don't trust a CA to issue EE certs with proper EKUs, then you shouldn't
>accept the CA. But if there is a need to use EKU, and to limit it by
>CA, then that need should be satisfied with a clean mechanism, not by
>bastardizing the CP extension.
>
I believe that a mechanism such as the EKU could serve a useful purpose, not as a key usage per se, but rather as a rights management tool. But in that case we need a compact and easily computable way to control delegation.
Perhaps it is time to rethink these approaches, as we seem to be discovering problem after problem.
Regards,
Bob
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19726 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 14:15:14 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13233 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 15:22:40 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA22488 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 17:22:39 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id RAA25982 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 17:22:38 -0500 (EST)
Message-ID: <3A11BAAC.4140F4EF@sun.com>
Date: Tue, 14 Nov 2000 17:20:28 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Cross-organizational ACs
References: <sa10f961.033@prv-mail20.provo.novell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I have recently confirmed with the ac509 authors that they did not mean
to prohibit an AC verifier from trusting multiple AC issuers for a given
attribute. They are planning to change the text in section 1.1 to make
this clear. This should provide more flexibility for organizations that
want to run multiple AC issuers.
However, I still think there are several unresolved issues with
cross-organizational ACs (where the issuer and the verifier are in
different organizations, especially with limited trust).
1) As Anders pointed out, in the pull scenarios the AC verifier may not
know where to get an AC issued by another organization. We could add
a pointer in the PKC saying how to get ACs for the subject, but I
suspect that won't work very well due to the political and technical
issues raised by Bob Jueneman. In all likelihood, pull scenarios
will only use ACs from the verifier's organization.
2) With cross-organizational ACs, the AC verifier should not need to be
configured with a complete list of trusted AC issuers. Otherwise,
all AC verifiers will need to be updated whenever the list of
trusted organizations changes. This would be especially bad with
S/MIME, since each email client is an AC verifier.
This problem can be addressed with the AAControls extension. The
verifier trusts one or more AA CAs (probably run by their own
organization). These AA CAs issue PKCs with the AAControls
extension, vouching for AC issuers or other AA CAs. The AAControls
extension includes constraints on the path length to an AC issuer or
the attribute types that may be issued.
Unfortunately, I suspect that these constraints will not be
sufficient for most organizations. For instance, one organization
may trust another to issue ACs containing the Group attribute, but
only for certain groups. Or they might trust them to issue ACs with
the Clearance attribute, but not for the topSecret class.
If we were using delegation (a la X.509 2000), this could be handled
by domination rules. At the risk of opening a huge can of worms,
I'll inquire why we're creating our own delegation system (AA CAs)
instead of profiling the system provided by X.509.
-Steve
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15811 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 11:53:20 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27894; Tue, 14 Nov 2000 13:00:42 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA15006; Tue, 14 Nov 2000 15:00:08 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id PAA16456; Tue, 14 Nov 2000 15:00:08 -0500 (EST)
Message-ID: <3A119946.59408AF3@sun.com>
Date: Tue, 14 Nov 2000 14:57:58 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Gindin/Watson/IBM <tgindin@us.ibm.com>
CC: ietf-pkix@imc.org
Subject: Re: Holder
References: <OFE309F0CD.FAD54440-ON85256993.00595781@somers.hqregion.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Do you have a specific example where an AC whose Holder component was
tied to a PKC would accompany a signed document (or other object) but
the PKC would not? This seems somewhat unlikely to me.
I don't mind recommending format 9 instead of format 5, based only on
easier debugging and a suspicion that the entityName might some day be
useful for finding the PKC. But I would be more comfortable if we had a
specific scenario where the entityName is needed to find the PKC.
-Steve
Tom Gindin/Watson/IBM wrote:
>
> The primary use I can think of for format 7, 9, or 11 is to permit an
> AC to accompany (or simply be stored with) a signed document, transaction,
> or message without requiring the PKC to do so. The RP can then look up the
> PKC. As I have stated before, in any case like this format 11 or format 9
> is preferable to format 5. Formats 4 and 5 are appropriate when the PKC
> accompanies the AC or precedes it in a protocol, but not otherwise.
> Since format 9 (or format 11) is preferable to format 5 when the AC is
> sent or stored independently of the PKC and also carries out all the
> functions of format 5, I would replace your references to format 5 by
> references to format 9 (or format 11). Formats 2, 4, and 9 make a
> reasonable minimal set, as do 2, 4, and 11.
>
> Tom Gindin
>
> Steve Hanna <steve.hanna@sun.com> on 11/10/2000 10:56:55 AM
>
> To: ietf-pkix@imc.org
> cc:
> Subject: Re: Holder
>
> Well, my list of scenarios does not seem to be helping us resolve this
> issue.
>
> I will make a specific proposal, seeking comments or consensus. Since
> none of the scenarios demonstrates a need for hints in Holder formats
> that include the objectDigestInfo component, I propose that we adopt the
> following recommendation, which would be incorporated into the next
> version of ac509 (along with text explaining the various formats, how
> they must be handled for validation purposes, and why each one might be
> preferred to the others).
>
> AC issuers SHOULD use only formats 2, 4, or 5. They MAY use other
> formats, as necessary. AC verifiers SHOULD support formats 2, 4, and
> 5 (subject to specific requirements and configuration). They MAY
> support other formats.
>
> I welcome comments from others on this proposal. A good argument can be
> made for replacing format 5 with format 9, if only for debugging
> purposes. But I'd rather not recommend support for both, if possible.
>
> -Steve
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA07676 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 09:09:03 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id MAA15578; Tue, 14 Nov 2000 12:16:21 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v0422080cb6371ef950b6@[171.78.30.108]>
In-Reply-To: <000001c04d00$25f0a300$e8c80318@etntwn1.nj.home.com>
References: <000001c04d00$25f0a300$e8c80318@etntwn1.nj.home.com>
Date: Tue, 14 Nov 2000 12:01:14 -0500
To: "Peter H. Gien" <pgien@home.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: OCSP-X vs SCVP
Cc: <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Peter,
>Dan,
>
>Forgive me if I digress from the original topic.
>Let's agree that ASN.1 and XML are not really languages such as C and Java.
>As such, ASN.1 and XML are simply tag formats that are used to describe
>data. I cannot compile ASN.1 nor can I execute XML. The use of one or the
>other would not necessarily result in "code bloat". Data bloat yes.
One can compile ASN.1 into various programming languages, e.g., C++.
Such compilers have been available for 10-15 years. That is one
reason for adopting it for protocol data format description. One
should also distinguish between the syntax specification aspects of
ASN.1 and the encoding rules, something your text above does not do.
>One thing that is for sure though, is that any budding VB programmer can
>open an XML document without any trouble. MSXML.DLL is already on their
>machine and it opens the document as if by magic. A little more study,
>effort and insight is needed to open an ASN.1 file. (OK, a lot more...)
Not on my Mac, I suspect :-).
>I'd like to add that going forward, XML should be a standard way of
>describing all PKIX data structures. Think what has happened to assembly
>programming? Delegated to the specialist backwaters of computing (Too much
>studying, effort and insight was required). It was replaced with C and
>shortly thereafter with C++. The same analogy applies to ASN.1 and XML. The
>standard that requires the least amount of intellectual effort to comprehend
>and implement is the one that wins. This does not always translate to the
>best standard!)
I'm still in favor of creating the best standards in this WG.
Steve
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA07577 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 09:08:35 -0800 (PST)
Received: from mega (t7o69p205.telia.com [213.65.46.205]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id SAA22651; Tue, 14 Nov 2000 18:15:24 +0100 (CET)
Message-ID: <006701c04e5e$4891f030$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>
Cc: <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se> <v04220800b636f37d3545@[171.78.30.108]>
Subject: Re: Should PKIX protocols support XML well
Date: Tue, 14 Nov 2000 18:14:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA07578
Steve,
>Although ACs are generally assumed to be more dynamic than PKCs, but different usage models
>call for different validity intervals. Thus I don't agree that they are as message like as you suggest.
>The XML-based schema you suggest would be more flexible, and arguably less interoperable.
Here we apparently differ. IMO AC are potentially *extremely* application-dependent
which makes interoperability an entirely different story than for PKCs.
That an AC-app using "my" scheme would reject anything that does not *exactly* match a
(usually very limited) set of known AC-app-specific schemas is *by design*. I.e. there is no
(will not be is probably more correct), such thing as a generic AC application.
There can (and should) still be a framework but it should be split into a standardized part and
one which is entirely application-defined. Then you can create a generic AC reader/verifier.
BTW, take a look on the postings
"With XML-ACs extensions become unnecessary"
and
"XML-AC - Sample Java Code"
Anders
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05497 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 08:42:40 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id LAA09179; Tue, 14 Nov 2000 11:50:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04220800b636f37d3545@[171.78.30.108]>
In-Reply-To: <008501c04dca$78a3b0e0$0201a8c0@vincent.se>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]> <008501c04dca$78a3b0e0$0201a8c0@vincent.se>
Date: Tue, 14 Nov 2000 08:55:51 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well
Cc: <ietf-pkix@imc.org>
Content-Type: multipart/alternative; boundary="============_-1237901773==_ma============"
--============_-1237901773==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 12:35 AM +0100 11/14/00, Anders Rundgren wrote:
>Steve,
>
> > XML has various benefits for representing certain kinds of data, but
> > none of those seem especially relevant to the encoding of certs or
> > CRLs.
>
>Agreed, assuming we talk PKCs. ACs are rather different creatures as they
>are functionally comparable to "messages", featuring a possibly
>dynamic, application-specific,
>information-rich content, that is to be fully digested (by the
>application) and acted upon, in
>contrast to static PKCs that usually only identify an entity. And
>each AC "message type" would
>benefit *tremendously* by being expressed as a *unique* XML schema
>instead of being "squeezed"
>into the current "one-size-fits-all try-to-guess-this-ac-profile" approach.
Although ACs are generally assumed to be more dynamic than PKCs, but
different usage models call for different validity intervals. Thus I
don't agree that they are as message like as you suggest. The
XML-based schema you suggest would be more flexible, and arguably
less interoperable. Also, we have lots of examples of how more
dynamic, more flexible aspects of applications lead to security
problems, e.g., the many e-mail attacks based on scripting
capabilities. So, flexibility has it downside in security contexts.
>
> > Moreover, at a time when people in various quarters (e.g.,
> > wireless folks) complain about the size of certs, it would not seem
> > especially appropriate to adopt an XML encoding, which would increase
> > the size of these data items.
>
>These guys have so far had practically zero success in deployment due to high
>traffic costs and slow transmission. I would not consider their arguments
>that important when the general expectancy is streaming multimedia
>in our phones
>next year or so. In that perspective PKIX structures look real neat and tiny.
I have not considered their arguments too seriously, for various
reasons, but I use those arguments as an example of the wide range of
often conflicting "requirements" that are proposed.
Steve
--============_-1237901773==_ma============
Content-Type: text/enriched; charset="us-ascii"
At 12:35 AM +0100 11/14/00, Anders Rundgren wrote:
<excerpt>Steve,
> XML has various benefits for representing certain kinds of data, but
> none of those seem especially relevant to the encoding of certs or
> CRLs.
Agreed, assuming we talk PKCs. ACs are rather different creatures as
they
are functionally comparable to "messages", featuring a possibly
dynamic, application-specific,
information-rich content, that is to be fully digested (by the
application) and acted upon, in
contrast to static PKCs that usually only identify an entity. And each
AC "message type" would
benefit *tremendously* by being expressed as a *unique* XML schema
instead of being "squeezed"
into the current "one-size-fits-all try-to-guess-this-ac-profile"
approach.
</excerpt>
Although ACs are generally assumed to be more dynamic than PKCs, but
different usage models call for different validity intervals. Thus I
don't agree that they are as message like as you suggest. The XML-based
schema you suggest would be more flexible, and arguably less
interoperable. Also, we have lots of examples of how more dynamic, more
flexible aspects of applications lead to security problems, e.g., the
many e-mail attacks based on scripting capabilities. So, flexibility
has it downside in security contexts.
<excerpt>
> Moreover, at a time when people in various quarters (e.g.,
> wireless folks) complain about the size of certs, it would not seem
> especially appropriate to adopt an XML encoding, which would increase
> the size of these data items.
These guys have so far had practically zero success in deployment due
to high
traffic costs and slow transmission. I would not consider their
arguments
that important when the general expectancy is streaming multimedia in
our phones
next year or so. In that perspective PKIX structures look real neat
and tiny.
</excerpt>
I have not considered their arguments <underline>too</underline>
seriously, for various reasons, but I use those arguments as an example
of the wide range of often conflicting "requirements" that are
proposed.
Steve
--============_-1237901773==_ma============--
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA29566 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 07:29:06 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 14 Nov 2000 08:35:45 -0700
Message-Id: <sa10f961.032@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 14 Nov 2000 08:35:46 -0700
From: "Bob Jueneman" <bjueneman@novell.com>
To: <steve.hanna@sun.com>, <anders.rundgren@telia.com>
Cc: <ietf-pkix@imc.org>
Subject: Re: AC Scenarios - PULL model
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA29567
>Steve,
>
>> ac509prof (section 5) says that "The AC issuer MUST be directly trusted
>> as an AC issuer (by configuration or otherwise)." It also says (section
>> 1.1) "This specification deals with the simple cases where one authority
>> issues all of the ACs for a particular set of attributes."
>>
>> Therefore, I expect that the AC verifier will only have a single trusted
>> AC issuer (or one for each set of attributes). Because of this, the AC
>> verifier (in the pull scenarios) should be able to pull all ACs from a
>> single repository or AC issuer (or one for each set of attributes).
>> There is no need for the PKC to include information about where to find
>> ACs. In the AC pull scenarios, the AC verifier will have this
>> information already configured. This model works in either an intranet
>> or an extranet case. The PKC may be issued by a third-party CA. But the
>> AC will always come from the single trusted AC issuer.
>
>That's my definition of a system that does not scale and have severe
>built-in security problems. I.e. multi-party update/access to a single repository
>containing fairly dynamic individual-specific information. A single issuer is
>*not* a requirement so far as I can see. It that really is the case this scheme
>needs a *major* fix which I BTW see no chance of accomplishing.
>
>Question from a directory "Newbe": Can interlinked directories administered by
>the "business parties" themselves, form a virtual single repository (and therefore
>single verifier configuration), supporting multiple AC issuers?
>
>Anders
>
Anders, we refer to such "interlinked" directories as "federated". And we have made some considerable amount of effort to support such federation. But speaking only personally, and not someone who is a bone fide directory savant, although I think the technical problems are solvable, I suspect that the management problems are not -- at least not very easily.
Just consider how much effort has gone into trying to define a common schema between two disparate directories, for example when two companies merge. It is a major, major headache, and likely to cause all sorts of backwards compatibility problems with existing applications. And that is sort of the best case, when there are only two players, and they are cooperative and mutually trusting. (Having gone through some mergers, I'm biting my tongue a little bit on that one. :-)
Now consider the problem when multiple parties want to federate their directories. Not only to the schemas have to be aligned, but all of the rights management and everything else. And then there is the transitive trust issue -- if A decides to trust B to access (read or write) A's data, and B decides to trust C, does that mean that A trusts C? Not necessarily, yet with the usual type of ACLs (discretionary access controls) it is very difficult to manage such rights.
For these political reasons, over and above the technical ones, I think you are exactly correct. A single issuer is not likely to work, IMHO.
Bob
Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23093 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 06:36:16 -0800 (PST)
Received: from mega (t4o69p13.telia.com [62.20.145.133]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id PAA29777 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 15:43:39 +0100 (CET)
Message-ID: <003601c04e49$15edf7b0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "PKIX-List" <ietf-pkix@imc.org>
Subject: With XML-ACs extensions become unnecessary
Date: Tue, 14 Nov 2000 15:42:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA23095
Hi,
Some interesting things happen when you put the application-part of
a protocol etc. in an app-specific XML schema. E.g. like in MSFT's BizTalk.
If the AC designers (using a single ASN.1 "schema"), have not thought of
"everything" that AC apps need, the apps will have to use extensions. The more
extensions you get the less "tasty" the cake will be. And the lower (generic) part of
the parser will not be able to do very much processing of extensions except collecting
objects. Leaving a lot of guesswork and checks to the application-level. Isn't this
what programmers have been taught to avoid the last 20 years or so?
With application-specific AC schemas the word extension becomes virtually
redundant since every app defines their own favorite attribute mix. Like 4 passwords
"p1", "p2", "p3" and "p4" per userID instead of just one. Can't be done using ASN.1 without
changing the AC profile or turn to extensions. Probably a *really* stupid example but
it shows the lack of flexibility in the current scheme. Revisions, revisions, revisions...
Or extensions, extensions, extensions...
These schemas can still be a part of a generic AC framework so
there *is* still a need for that.
Note: This is just *one* part of the suggestion.
Anders
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22354 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 06:21:11 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA26680; Tue, 14 Nov 2000 15:34:28 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA14780; Tue, 14 Nov 2000 15:27:17 +0100
Message-ID: <3A114BC7.D0B4FFA9@bull.net>
Date: Tue, 14 Nov 2000 15:27:19 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <ambarish@valicert.com>
CC: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FB9@exchange.valicert.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ambarish,
> Hi Steve/Russ,
> I hope nothing that I posted even implied that I recommend that
> certs and CRLs be encoded in XML. I think there is enough investment
> in ASN.1 certs/CRLs etc. to not make it a worthwhile effort. The
> remark I was trying to make is that I think future PKIX work should
> try and see if specifying protocols in XML or both XML and ASN.1
> make sense for the task they are trying to do.
>
> This is precisely why I tried to specify SCVP in both syntaxes.
Let me jump into this discussion. ASN.1 has been used historically to define
*protocols*. Since such protocols were carrying data structures that could
have their own existence outside their transmission in the protocols, we
ended up with ASN.1 for *data structures*. The prime examples are
certificates and CRLs.
The basic question is thus NOT whether we should specify new protocols in
ASN.1, XML or both XML and ASN.1, but rather whether we want to define NEW
data structures in XML or ASN.1. As an example, an OCSP response is an ASN.1
data structure that has an existence beyond its transmission in the
protocol, since it can be stored and re-used to make sure, e.g., it was
correctly signed.
The basic question is thus the following : should new data structures,
signed by an authority, which would vouch for the validity (they are various
flavors around that term) of a certificate or certificate chain against some
rules be defined in ASN.1 and/or XML ?
Let me just provide one first argument: ASN.1 is much more compact than XML.
There are other arguments indeed. You are welcome to provide them.
Denis
> Regards,
> Ambarish
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect 650.567.5457
> ValiCert, Inc. ambarish@valicert.com
> 339 N. Bernardo Ave. http://www.valicert.com
> Mountain View, CA 94043
>
> > -----Original Message-----
> > From: Stephen Kent [mailto:kent@bbn.com]
> > Sent: Monday, November 13, 2000 11:04 AM
> > To: Ambarish Malpani
> > Cc: 'ietf-pkix@imc.org '
> > Subject: Re: Should PKIX protocols support XML well
> >
> >
> > Ambarish,
> >
> > XML has various benefits for representing certain kinds of data, but
> > none of those seem especially relevant to the encoding of certs or
> > CRLs. Moreover, at a time when people in various quarters (e.g.,
> > wireless folks) complain about the size of certs, it would not seem
> > especially appropriate to adopt an XML encoding, which would increase
> > the size of these data items.
> >
> > I am not persuaded by comments that allude only to the "trendiness"
> > of XML vs. ASN.1 encoding, as several others have pointed out. PKIX
> > was started as a profiler of X.509 protocols, and we have expanded
> > our charter to create new protocols that support X.509 certs and
> > which seem appropriate to PKI use in the Internet. That makes it hard
> > to justify developing new syntax for existing data structures, as
> > noted above. However, as Russ pointed out, standards for carriage of
> > certs and CRLs (ASN.1 encoded) in an XML context are not out of the
> > question.
> >
> > Steve
> >
>
> ----------------Russ's Original Message-------------
> Ambarish:
>
> I agree that we need to support XML clients. It would not have been one of
> my three criteria if I thought otherwise. However, I do not think that we
> should abandon ASN.1. I think that certificates and CRLs MUST be ASN.1
> encoded. Providing an XML wrapper to carry an ASN.1-encoded blob is just
> fine. Base64-encode it if you like. Anyway, the server can obtain the
> ASN.1-encode certificate perform validation services. The server will
> return an indication of validity and parse some information (especially the
> public key, alt names, and critical extension information) from the
> certificate. This will allow the client to be completely ASN.1 ignorant.
>
> I realize that this is just one aspect of making the entire system XML
> client friendly; however, I think that it is a very reasonable place to
> begin. In many systems, enrollment is handled by issuing a token (such as
> a smart card). In this case, the client has nothing to do with
> enrollment. So, certificate validation is a good place to begin.
>
> Russ
> -------------End of Message----------------------------
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11444 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 03:37:28 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09899; Tue, 14 Nov 2000 06:44:53 -0500 (EST)
Message-Id: <200011141144.GAA09899@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-roadmap-06.txt
Date: Tue, 14 Nov 2000 06:44:53 -0500
Sender: nsyracus@cnri.reston.va.us
--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
Author(s) : A. Arsenault, S. Turner
Filename : draft-ietf-pkix-roadmap-06.txt
Pages : 51
Date : 13-Nov-00
This document provides an overview or 'roadmap' of the work done by
the IETF PKIX working group. It describes some of the terminology
used in the working group's documents, and the theory behind an
X.509-based Public Key Infrastructure, Privilege Management
Infrastructure (PMI), and Time Stamping and Data Certification
Infrastructures. It identifies each document developed by the PKIX
working group, and describes the relationships among the various
documents. It also provides advice to would-be PKIX implementors
about some of the issues discussed at length during PKIX
development, in hopes of making it easier to build implementations
that will actually interoperate.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-06.txt
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-roadmap-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:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-pkix-roadmap-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="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001113134819.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-roadmap-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-roadmap-06.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001113134819.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA07631 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 02:58:42 -0800 (PST)
Received: from mega (t6o69p17.telia.com [213.64.110.137]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id MAA12773 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 12:06:05 +0100 (CET)
Message-ID: <013401c04e2a$b11748a0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "PKIX-List" <ietf-pkix@imc.org>
Subject: XML-AC - Sample Java Code
Date: Tue, 14 Nov 2000 12:04:37 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA07633
Hi,
I would like to give you a programmers view of the XML-AC suggestion.
Assumption: Each AC application has it *own* schema (instead of the current
one-size-fits-all-try-to-guess-this-profile approach). They share a common
header [schema] document though that indicates that they really are an AC etc.
Some "virtual java-code":
ACReader o = new ACReader (); // Generic code supplied by the "system"
o.read (inputstream); // Reads the entire AC structure, verifies signatures, checks syntax and
// extracts the AC application-specfic schema
If (!o.getAppSchemaName ().equals ("http://www.server.com/my-database-login-thing"))
{
throw new IOException ("I don't eat this s**t!");
}
// Now we have the AC data. Extract it and do something with it
handle = performDBLogin (o.getProp ("UserID"), o.getProp ("Password"));
// Note: We KNOW that "UserID" and "Password" exist due to the schema!
With the exception of the data extraction part which probably requires a little more
tree-navigating using DOM/SAX APIs (but not testing), this is what we should get.
Based on a 100% generic reader-code that does not have to be "adjustable".
===================================================
The above can IMO not be done with the current ASN.1-based AC system.
====================================================
Note: I deliberately excluded the PKC link part but it should have a pretty general
solution hopefully only requiring a few property settings.
Anders R
Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA02220 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 02:04:09 -0800 (PST)
Received: (qmail 97588 invoked from network); 14 Nov 2000 10:11:32 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 14 Nov 2000 10:11:32 -0000
Received: (qmail 24892 invoked from network); 14 Nov 2000 10:11:58 -0000
Received: from mnystrom-lap.d.dynas.se (172.16.13.246) by spirit.dynas.se with SMTP; 14 Nov 2000 10:11:58 -0000
Date: Tue, 14 Nov 2000 11:11:30 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <magnus@rsasecurity.com>
To: Bob Jueneman <bjueneman@novell.com>
cc: ietf-pkix@imc.org
Subject: Re: WAP X.509 Certificate profile specification
In-Reply-To: <sa1007a4.044@prv-mail20.provo.novell.com>
Message-ID: <Pine.WNT.4.10.10011141055290.-489765@mnystrom-lap.d.dynas.se>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id CAA02221
Bob,
Thanks for your comments.
On Mon, 13 Nov 2000, Bob Jueneman wrote:
> The Novell Certificate Server was architected to support multiple CA
> server's running concurrently in a distributed system. In order to
> avoid possible synchronization problems, we use a SHA-1 hash of a
> 128-bit machine-unique ID and a 32-bit local machine-specific serial
> number to form a 160-bit (20 byte) certificate serial number. (Yes, I
> understand that this only provides probabilistic uniqueness, but I'll
> take the risk, and worry about it after generating 2^80 certificates.)
>From your description, it seems that for a given machine, The probability
of issuing two certificates with the same serial number is approx 0.5
already after that machine has issued 2^16 certificates (assuming that the
machine-unique ID remains invariant over time). But I may well have
misunderstood, in which case I apologize for the confusion.
> Although I'm sympathetic to processor power limitations for WAP
> devices, you would think by now we had learned our lesson with respect
> to setting artificial memory limitations. Remember when 640K of
> memory was all that a PC would ever need? Remember Y2K??
>
> The reason for using ASN.1 was to avoid these kinds of problems, and I
> see no reason to change or revisit those decisions. 20 bytes, or even
> more, won't break the bank.
Yes - and hence this is only a recommendation, not a "MUST". Clients
should handle longer serial numbers, but there are some bandwidth (and
storage space) to be saved by limiting their length.
> If they really want to save certificate space, they should mandate the
> use of UTF-8 for DNs, especially for the Asian languages, rather than
> using BMPString.
The WAP Certificate Profile does recommend the use of UTF8 (and, in line
with 2459, mandates its use after December 31, 2003). Further, since WAP
clients are not mandated to be able to display values of types other than
NumericString, PrintableString and UTF8String, this will hopefully be an
incitement to move away from BMPString (which is not mentioned in the WAP
Cert Profile).
-- Magnus
Magnus Nystrom
RSA Security
> >>> $(G¤ý¤å¥¿ <wcwang@ms.chttl.com.tw> 11/03/00 11:24PM >>>
> Hi Magnus,
>
> I've downloaded the WAP X.509 certificate profile specification, and noticed
> that there is a recommendation on the length of Certificate Serial Number:
>
> 6.2.1 Certificate Serial Number
> CAs claiming conformance with this specification should avoid using
> serial numbers longer than 8 bytes (63 bits, topmost bit cannot be set to
> 1).
>
> I believe that the recommendation is due to the limit memory space and
> processing power of WAP device. However, I suggest that the specification
> should extend the limitation on the length of certificate serial numbers
> from
> 8 bytes to at least 16 bytes, since there are many root CA's and
> intermediate
> CA's are currently usning 16-byte certificate serial numbers. By allowing
> merely more 8 bytes be used for certificate serial numbers, existing CA's
> may issue WAP-compliant certificates without changing their algorithms for
> generating certificate serial numbers.
>
> --
> Wen-Cheng Wang
> Telecommunication Lab.
> Chunghwa Telecom Co., Ltd.
>
> On Mon, 30 Oct 2000, Magnus Nystrom wrote:
> > Hi Tom,
> >
> > I would suggest that you send them directly to me, unless they are
> > pkix-related. I will make sure to forward them to WAP's security group
> > mailing list - and Cc: you.
> >
> > Thanks,
> > -- Magnus
> >
> > On Mon, 30 Oct 2000, Tom Arnold wrote:
> >
> > I've downloaded the document and am beginning to review it. My company is
> > not a member of the Wap Forum... As such, if I have comments, where
> should
> > I send them? I'm assuming the PKIX list is not the correct location...
> >
> > At 04:19 PM 10/26/2000 +0200, you wrote:
> > >Dear PKIX members,
> > >
> > >On behalf of WAP's security group WSG, I would like to inform you that
> > >a document named "WAPCert-20000309" can be found at
> > >
> > >http://www.wapforum.org/what/technical.htm.
> > >
> > >This document describes X.509 certificate profiles to be used for those
> > >cases when X.509-compliant certificates will be sent over-the-air in WAP
> > >protocols (or stored locally in WAP clients).
> > >
> > >An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> > >
> > >Comments and suggestions related to these documents are welcome and
> > >solicited.
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA00434 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 01:44:28 -0800 (PST)
Received: from asn-1.com (user-2ivf54t.dialup.mindspring.com [165.247.148.157]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id EAA05501 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 04:51:51 -0500 (EST)
Message-ID: <3A110BF1.61C35B50@asn-1.com>
Date: Tue, 14 Nov 2000 04:54:57 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: OCSP-X vs SCVP
References: <200011131449.JAA13360@roadblock.missi.ncsc.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"David P. Kemp" wrote:
>
> > From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
> >
> > This will provide a means to extend the capability
> > deployed today - the ability to unambiguously encode
> > and decode a value of an ASN.1 type. A standard markup
> > for the ASN.1 notation will provide a new format for
> > expressing the same ASN.1 values.
> >
> > By binding a standard markup to the values defined as
> > valid for ASN.1 types, it will be possible for an ASN.1
> > application to send or receive ASN.1 values in either
> > text or binary formats.
>
> Phil,
>
> This description does not do justice to the powerful advantages a
> standard XML schema would provide. See below.
David,
I seek a broader solution than just support for
XML-schema base text transfer. My goal is to support
transfer of all, and of the exact same set of values
in binary and text. And I wish to be able to exchange
these values with the biggest possible community.
I wish to exchange data with folks that simply use
XML markup, XML markup with DTD, XML markup with
RELAX, XML markup with DT4-DTD, XML markup with
XML-schema, XML markup with ASN.1 schema, and
others. I seek a solution that allows me to not
simply transfer XML, but to transfer textual
ASN.1 values tailored to the many XML derivative
markup communities.
My default behavior is simply to exchange values
with communities that use binary and XML markup
solutions. This requires no further definition
than the current ASN.1 notation. But I also
propose to allow additional notation, defined in
an associated file that gives the application
writer the ability to completely control the
form of generated markup.
snip
>
> The idea of a standard XML schema is that each protocol would *not*
> need to specify how to translate one to the other. Every protocol
> would use the same translation.
My idea is to guarantee that values can actually
be exchanged by automatically generating valid
XML markup containing valid ASN.1 values. Of
course, the non ASN.1 application could augment
these values as it desired, adding its own DTD,
DT4-DTD, schema, stylesheet, etc. But these would
not interfere with the format or content of the
data exchange.
> The protocol document ensures that the ASN.1 and the XML specifications
> are equivalent (by mechanically generating one from the other), and
> once that is done, the VB programmer doesn't have to know jack about
> ASN.1 in order to write an application which exchanges data to and from
> an ASN.1 application operating in text mode!
In some ASN.1 specifications this approach may be
possible. But in general, these two schema are not
equivalent. But even where they are, this approach
does not help all XML communities - just one.
> Anders seems puzzled that his suggestion to discard ACs and replace
> them with something written in XML was not warmly received, but that
> specifying SCVP etc in both ASN.1 and XML seems to be getting more
> support. This is not puzzling; the former involves inventing something
> 'equivalent' from scratch, whereas the latter involves first
> standardizing the information to be exchanged and then writing two
> equivalent ways of encoding that information. Applications can be
> developed completely independently - XML developers use their favorite
> tools to implement the XML protocol specification, ASN.1 developers use
> their favorite tools to implement text mode encoding from the ASN.1
> protocol specification, and the two applications work together.
>
> I believe that PKIX should evolve to include both ASN.1 and XML
> specifications of each protocol, and should require that those
> specifications be equivalent for each protocol which includes
> an XML specification.
>
> > From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
> >
> > What I am proposing is to modify the ASN.1
> > standards so that the values of all ASN.1 types can
> > be expressed using a common XML markup.
>
> I agree. But just as RFC 2459 includes both 88 and 92 appendices,
> PKIX documents should include both ASN.1 and standalone XML appendices.
I believe that a best ASN.1/XML solution would
serve the needs of the broadest XML (and HTML
or XHTML) community. That can best be accomplished
by what seems to be the most simple approach. All
of the XML communities understand marked up values.
This is the common link I seek to exploit for textual
data exchange of binary values.
Phil
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA24410 for <ietf-pkix@imc.org>; Tue, 14 Nov 2000 00:59:04 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id BAA09534; Tue, 14 Nov 2000 01:00:42 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <W6GH5Q9A>; Tue, 14 Nov 2000 01:04:31 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F401C5B459@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: Ambarish Malpani <ambarish@valicert.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
Date: Tue, 14 Nov 2000 01:04:30 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Ambarish,
FYI, DPV and DPD can work with RFC2560. They link into RFC2560's existing
extension mechanisms. They also work with OCSPv2, so there's leverage
either way. RFC2560's ASN.1 requirement in certID for a hash of the CA's
public key can be met by a null value for the hash of the CA's public key;
RFC2560 imposes no ASN.1 constraints on this value. A standards-based
rationale for this practice would be useful. We believe it better though to
expand the definition of certID, hence OCSPv2. We hope you agree. BTW, the
certID issue in no way stimulated production of the DPV and DPD proposals.
With respect,
Mike
Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA27109 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 16:51:53 -0800 (PST)
From: rsalz@CaveoSystems.com
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 05869940 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 19:58:49 -0500 (EST)
Received: (from rsalz@localhost) by os390.caveosystems.com (8.9.3/8.9.3) id TAA23174 for ietf-pkix@imc.org; Mon, 13 Nov 2000 19:58:58 -0500
Date: Mon, 13 Nov 2000 19:58:58 -0500
Message-Id: <200011140058.TAA23174@os390.caveosystems.com>
To: ietf-pkix@imc.org
Subject: XML for PKIX data structures
X-Loop-Detect: 1
This is a rather long message. It contains a worked example of how XML
might be used in PKIX protocol definitions: a base schema, a sample
protocol, and PDU instance of the protocol. At the end of the note is
a suggestion for future action.
First is a moderately complete schema definition for "extension"
the (oid,criticality,value) triplet that appears all over the place.
To encourage re-use, it appears as part of "pkix base" schema (that I
just made up). There are a couple of open issues, search for XXX.
<xsd:schema
targetNamespace="http://www.ietf.org/pkix/base"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig">
<xsd:annotation><xsd:documentation>
Definition of some base types for IETF PKIX work.
XXX Copyright statement goes here.
</xsd:documentation></xsd:annotation>
<xsd:simpleType name="oidType">
<xsd:annotation><xsd:documentation>
XXX Are leading zero's allowed in OID's?
</xsd:documentation></xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[1-9][0-9]*(\.[1-9][0-9]*)*"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="criticalityType">
<xsd:annotation><xsd:documentation>
We define this so that in the future we can allow 0/1,
t/nil, etc., as false/true values if we want.
</xsd:documentation></xsd:annotation>
<xsd:restriction base="xsd:boolean"/>
</xsd:simpleType>
<xsd:complexType name="extensionbaseType">
<xsd:annotation><xsd:documentation>
This defines the basic extension, an element with three
attributes -- OID, criticality (defaults to false), and
an optional name hint. It can have "data", which is
base-64 encoded binary data, and/or "content" which is
XML syntax, representing the value of the extension.
The semantics are undefined if the two disagree.
</xsd:documentation></xsd:annotation>
<xsd:attribute name="oid" type="oidType" use="required"/>
<xsd:attribute name="criticality" type="criticalityType"
value="false"/>
<xsd:attribute name="name" type="xsd:NMTOKEN"/>
<xsd:element name="data" type="ds:CryptoBinary" minOccurs="0"/>
<xsd:element name="content" type="xsd:any" minOccurs="0"/>
</xsd:complexType>
<xsd:complexType name="extensionlistType">
<xsd:element name="ext" type="extensionbaseType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:complexType>
</xsd:schema>
Whew -- that *is* verbose. But once we have the definition, using it
isn't too bad. Here's a fragment for a schema definition for some
PKIX type of operation (enrollment, OCSP, etc). This defines a request
as having a body (undefined) and then an optional list of extensions:
<xsd:schema
targetNamespace="http://www.ietf.org/pkix/sample"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
xmlns:pkix="http://www.ietf.org/pkix/base"
<xsd:element name="Request">
<xsd:complexType>
<xsd:element name="Body" type="..."/>
<xsd:element name="Extensions" minOccurs="0"
type="pkix:extensionlistType"/>
</xsd:complexType>
</xsd:schema>
Now, using that schema, here's a sample request (with the body omitted):
<Request xmlns="http://www.ietf.org/pkix/sample">
<Body>...</Body>
<Extensions xmlns="http://www.ietf.org/pkix/base">
<ext oid="2.2.840.10040.2.3"/>
<ext oid="2.5.29.14" name="id-ce-subjectKeyIdentifier">
<data>01M3S...</data>
</ext>
</Extensions>
</Request>
-------------------------------------------
I think it would be useful to define a PKIX "base" schema, and ideally
include a style guide. That way, if other protocol efforts (such as
SCVP) want to define an XML transport, it will be consistent and avoid
duplication of effort. I also think it makes sense to do this within
PKIX, analogous to the LDAP et. al operational protocols, or perhaps as
a joint effort with the xmldsig WG.
I'd be happy to start writing an I-D if there's interest. Any feeling
from the chairs where it should go?
/r$
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25357 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 15:31:17 -0800 (PST)
Received: from mega (t7o69p41.telia.com [213.65.46.41]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id AAA00429; Tue, 14 Nov 2000 00:37:22 +0100 (CET)
Message-ID: <008601c04dca$7a9d8510$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>, <ietf-pkix@imc.org>
References: <200011132025.PAA17449@roadblock.missi.ncsc.mil>
Subject: Re: OCSP-X vs SCVP
Date: Tue, 14 Nov 2000 00:35:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA25361
David,
I will try to explain this in another way
<snip>
> In contrast, I don't see how an XML schema, whether it is local/global/
> application/whatever, can communicate anything more about the semantics
> of a message (how it is to be acted upon) than can an ASN.1 type
> definition
<snip>
If my interpretation of the AC draft is correct, as well as my understanding that ASN.1 does
not support a schema/DTD the following is one of *many* reasons why XML DTD/Shemas
*would* make a difference if applied to ACs:
PKIX AC profile: A *single* definition for all possible AC application profiles
"Possible" XML-AC profile: Generic schema-defined header + application-specific schema for the actual
profile (the attributes).
An AC app is unlikely to bother about more than a few such application-specific shemas.
Most only understands one. A typical AC app simply rejects an unknown schema.
The major part of the work is therefore done by the XML-parser so the
application knows exactly (based on encountered schema having implict semantics) what to
process instead of doing own pattern matching, and data filtering. With XML schemas you
would typically specify a 1-to-1 fit with an application instead of "trying to be smart" and make
just about everything OPTIONAL, CHOICE, critical, non-critical etc.
===========================================================
If the ASN.1-AC approach (due to lack of schema) had been applied to BizTalk
(an XML-based business-message framwork), there would be a single definition
("business message profile") that would have had optional constructs for all kinds of
business messages. That would not have worked as it would be impossible to get
consensus, and would also have put an enormous burden on application developers.
===========================================================
I.e. IMO you SHOULD NOT structure things the same way when you have schemas
as you (are forced to) do in ASN.1. If you do, you could [almost] equally well stay with
ASN.1 as it is comparable with XML at the element level.
Anders
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25312 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 15:30:06 -0800 (PST)
Received: from mega (t7o69p41.telia.com [213.65.46.41]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id AAA00406; Tue, 14 Nov 2000 00:37:18 +0100 (CET)
Message-ID: <008501c04dca$78a3b0e0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Ambarish Malpani" <ambarish@valicert.com>, "Stephen Kent" <kent@bbn.com>
Cc: <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <v04220805b635ea7c6b39@[171.78.30.107]>
Subject: Re: Should PKIX protocols support XML well
Date: Tue, 14 Nov 2000 00:35:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA25313
Steve,
> XML has various benefits for representing certain kinds of data, but
> none of those seem especially relevant to the encoding of certs or
> CRLs.
Agreed, assuming we talk PKCs. ACs are rather different creatures as they
are functionally comparable to "messages", featuring a possibly dynamic, application-specific,
information-rich content, that is to be fully digested (by the application) and acted upon, in
contrast to static PKCs that usually only identify an entity. And each AC "message type" would
benefit *tremendously* by being expressed as a *unique* XML schema instead of being "squeezed"
into the current "one-size-fits-all try-to-guess-this-ac-profile" approach.
> Moreover, at a time when people in various quarters (e.g.,
> wireless folks) complain about the size of certs, it would not seem
> especially appropriate to adopt an XML encoding, which would increase
> the size of these data items.
These guys have so far had practically zero success in deployment due to high
traffic costs and slow transmission. I would not consider their arguments
that important when the general expectancy is streaming multimedia in our phones
next year or so. In that perspective PKIX structures look real neat and tiny.
<snip>
Regards
Anders
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23561 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 14:23:27 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA09004; Mon, 13 Nov 2000 17:30:46 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v0422080eb6361c451dae@[171.78.30.107]>
In-Reply-To: <004a01c04aec$27b84960$0201a8c0@vincent.se>
References: <A105E1C02F5DD31181A500508B5519EC3065AF@blue.identrus.com> <004a01c04aec$27b84960$0201a8c0@vincent.se>
Date: Mon, 13 Nov 2000 17:32:09 -0500
To: "Anders Rundgren" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: XML in PKIX. Was: OCSP-X vs SCVP
Cc: <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 8:59 AM +0100 11/10/00, Anders Rundgren wrote:
>RE: OCSP-X vs SCVPKhaja,
>
><snip>
>
> >The XML community I am referring to and am aware of is a group of
>financial institutions.
> >(There may be others) These financial institutions have a group
>of application and solution
> > developers within their ranks who (most of them) know and love
>XML. They prefer to avoid
> >dealing with ASN.1. This XML community finds it easier to read,
>deal with and encode
> >information in XML. They are able to debug protocol
>implementation problems where XML
> >encoding is used. They know and are comfortable with XMLDSIG and
>use that rather than
> >PKCS#7 to send signed transactions back and forth. They have
>plans to use delegated path
> >validation so they will not be doing PKIX section 6.1 stuff
>locally. They want to increasingly move
> >towards a set of protocols that use XML encoding for these reasons.
>
>I would say that this statement is valid for the e-business sector in general.
>
>According to some notable persons on this list, XML-encoded systems are not
>the target for PKIX as it is based on ISO-standards which currently
>are ASN.1-based.
>
>Steve K et al: Is'nt time to "adjust" the scope of PKIX and make the
>"X" not only refer
>to "X"500 but to "X"ML?
No, but thanks for asking.
Steve
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA23236 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 14:17:38 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 13 Nov 2000 15:24:20 -0700
Message-Id: <sa1007a4.043@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 13 Nov 2000 15:24:17 -0700
From: "Bob Jueneman" <bjueneman@novell.com>
To: <magnus@rsasecurity.com>
Cc: <ietf-pkix@imc.org>
Subject: Re: WAP X.509 Certificate profile specification
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA23237
The Novell Certificate Server was architected to support multiple CA server's running concurrently in a distributed system. In order to avoid possible synchronization problems, we use a SHA-1 hash of a 128-bit machine-unique ID and a 32-bit local machine-specific serial number to form a 160-bit (20 byte) certificate serial number. (Yes, I understand that this only provides probabilistic uniqueness, but I'll take the risk, and worry about it after generating 2^80 certificates.)
Although I'm sympathetic to processor power limitations for WAP devices, you would think by now we had learned our lesson with respect to setting artificial memory limitations. Remember when 640K of memory was all that a PC would ever need? Remember Y2K??
The reason for using ASN.1 was to avoid these kinds of problems, and I see no reason to change or revisit those decisions. 20 bytes, or even more, won't break the bank.
If they really want to save certificate space, they should mandate the use of UTF-8 for DNs, especially for the Asian languages, rather than using BMPString.
Bob
>>> $(G¤ý¤å¥¿ <wcwang@ms.chttl.com.tw> 11/03/00 11:24PM >>>
Hi Magnus,
I've downloaded the WAP X.509 certificate profile specification, and noticed
that there is a recommendation on the length of Certificate Serial Number:
6.2.1 Certificate Serial Number
CAs claiming conformance with this specification should avoid using
serial numbers longer than 8 bytes (63 bits, topmost bit cannot be set to
1).
I believe that the recommendation is due to the limit memory space and
processing power of WAP device. However, I suggest that the specification
should extend the limitation on the length of certificate serial numbers
from
8 bytes to at least 16 bytes, since there are many root CA's and
intermediate
CA's are currently usning 16-byte certificate serial numbers. By allowing
merely more 8 bytes be used for certificate serial numbers, existing CA's
may issue WAP-compliant certificates without changing their algorithms for
generating certificate serial numbers.
--
Wen-Cheng Wang
Telecommunication Lab.
Chunghwa Telecom Co., Ltd.
On Mon, 30 Oct 2000, Magnus Nystrom wrote:
> Hi Tom,
>
> I would suggest that you send them directly to me, unless they are
> pkix-related. I will make sure to forward them to WAP's security group
> mailing list - and Cc: you.
>
> Thanks,
> -- Magnus
>
> On Mon, 30 Oct 2000, Tom Arnold wrote:
>
> I've downloaded the document and am beginning to review it. My company is
> not a member of the Wap Forum... As such, if I have comments, where
should
> I send them? I'm assuming the PKIX list is not the correct location...
>
> At 04:19 PM 10/26/2000 +0200, you wrote:
> >Dear PKIX members,
> >
> >On behalf of WAP's security group WSG, I would like to inform you that
> >a document named "WAPCert-20000309" can be found at
> >
> >http://www.wapforum.org/what/technical.htm.
> >
> >This document describes X.509 certificate profiles to be used for those
> >cases when X.509-compliant certificates will be sent over-the-air in WAP
> >protocols (or stored locally in WAP clients).
> >
> >An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> >
> >Comments and suggestions related to these documents are welcome and
> >solicited.
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22518 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 13:59:07 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA22121; Mon, 13 Nov 2000 14:05:53 -0800 (PST)
Message-Id: <4.3.2.7.2.20001113163606.01a23e58@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 13 Nov 2000 17:00:16 -0500
To: Stephen Kent <kent@bbn.com>
From: Russ Housley <housley@spyrus.com>
Subject: Re: Should PKIX protocols support XML well
Cc: ietf-pkix@imc.org
In-Reply-To: <v04220805b635ea7c6b39@[171.78.30.107]>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Steve:
I agree with both of your points. However, XML-enabled clients are of
interest when those clients are using XML digital signatures.
I would like to see a solution where clients that are prepared to deal with
ASN.1 can get a signed response in the CMS format (RFC 2630), and clients
that are prepared to deal with Signed XML can get a response in that
yet-to-be-finalized format.
Further, the XML client should be able to treat the X.509 certificate as an
octet blob. They simply pass the certificate to the trusted server, and
the server returns a signed testament that the certificate is valid, the
public key, and alt names. There may be other fields that should be
returned, but we need to explore this model further to understand what they
might be.
Russ
At 02:04 PM 11/13/2000 -0500, Stephen Kent wrote:
>Ambarish,
>
>XML has various benefits for representing certain kinds of data, but none
>of those seem especially relevant to the encoding of certs or CRLs.
>Moreover, at a time when people in various quarters (e.g., wireless folks)
>complain about the size of certs, it would not seem especially appropriate
>to adopt an XML encoding, which would increase the size of these data items.
>
>I am not persuaded by comments that allude only to the "trendiness" of XML
>vs. ASN.1 encoding, as several others have pointed out. PKIX was started
>as a profiler of X.509 protocols, and we have expanded our charter to
>create new protocols that support X.509 certs and which seem appropriate
>to PKI use in the Internet. That makes it hard to justify developing new
>syntax for existing data structures, as noted above. However, as Russ
>pointed out, standards for carriage of certs and CRLs (ASN.1 encoded) in
>an XML context are not out of the question.
>
>Steve
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21875 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 13:34:11 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G3Z00001G981F@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 13 Nov 2000 13:41:32 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G3Z00MOVG989C@ext-mail.valicert.com>; Mon, 13 Nov 2000 13:41:32 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NLLLG>; Mon, 13 Nov 2000 13:39:34 -0800
Content-return: allowed
Date: Mon, 13 Nov 2000 13:39:28 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
To: "'Michael Myers'" <MMyers@verisign.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E152FBF@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Hi Mike,
Are you saying that DPV/DPD would work with RFC 2560? If so,
how would you expect to address the issue of the client having
the hash of the CA's public key to create the correct OCSP request,
when it wants the OCSP/DPV/DPD responder to build up the path to
a trusted CA?
I thought I had raised this point a few times before, and that was
at least part of the reason why you chose to put out OCSPv2 and
DPV and DPD at the same time.
Regards,
Ambarish
P.S. About the rest of the points that you raise, I suppose we will
continue to disagree.
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Michael Myers [mailto:MMyers@verisign.com]
> Sent: Monday, November 13, 2000 1:23 PM
> To: 'Ambarish Malpani'
> Cc: 'ietf-pkix@imc.org '
> Subject: RE: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
>
>
> Ambarish:
>
> As a I noted earlier, you need to split out the OCSPv2 draft
> from the DPV
> and DPD drafts. OCSPv2 simply expands on certificate identification
> mechanisms into well-known use cases while preserving backwards
> interoperability with existing 2560-compliant
> implementations. There's a
> few other tweaks but that's the core of it. I have embedded
> more specific
> comments below.
>
> With respect,
>
> Mike
>
>
>
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:ambarish@valicert.com]
> > Sent: Friday, November 10, 2000 1:42 PM
> > To: 'ietf-pkix@imc.org '
> > Subject: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
> >
> >
> >
> >
> > Here are some of my thoughts on why I think SCVP is the right
> > way to go ahead with remote path processing (RPP), rather than
> > creating a new version of OCSP (OCSPv2) and then defining OCSPpath
> > and OCSPvalid.
> >
> > Issues with OCSPv2
> > ------------------
> > - It causes uncertainity and concern about OCSP, even though there
> > aren't really any problems with the protocol itself
>
> There's no uncertainty that RFC2560 has been approved by PKIX
> and the IESG.
> The only uncertainty is whether or not the WG believes
> there's sufficient
> benefit to have certID (and a few other tweaks) fixed before RFC2560
> progresses further down the standards track.
>
> > - It will cause a bunch of interoperability issue with OCSP for
> > certificate status checks, because now you can identify a
> > certificate in many different ways
>
> The thing is, people are doing this already for a variety of
> reasons, so
> OCSPv2 isn't *causing* anything. Rather, it's responding to
> well-known
> needs.
>
> > - The semantics of what a server is required to do for a plain
> > OCSP request are unclear - does it need to check the expiry of
> > the certificate, what about the signature, etc on the cert?
>
> Please clarify if you're speaking to RFC 2560, OCSPv2 or DPV/DPD.
>
> > - It is unclear to me that the right thing to do is to change a
> > stable protocol just to add a bunch of new functionality, that
> > doesn't really do anything more for the base protocol.
>
> OCSPv2 does not create new functionality. It standardizes
> the basis for
> additional code development towards delivering 2560-based
> functionality into
> well-known use cases.
>
> > - If we go this route, we will take a lot longer to actually
> > reach a usable spec for RPP, because our first 12 months will
> > be spend debating the changes to OCSP
>
> SCVP's XML perspective may (should?) take into consideration
> all the variant
> opinions regarding the integration of XML with PKI and ASN.1.
> Given the
> abundance of recent WG comments, the timeframe is predictably the same
> either way.
>
> > - I would actually like the current OCSP, with some minor
> > clarifications and changing of the required signature algorithm
> > to RSA (from DSA), to continue on the standards track, we have
> > actually had a reasonable amount of interop testing on it
>
> It's my intent that the OCSPv2 draft will lead to an informed
> technical
> debate on all issues relevant to RFC2560's transition in status. Your
> preference for RSA as a SHALL vs. DSA as a SHOULD is noted.
>
> >
> > Issues with this approach
> > -------------------------
> > - It is very unclear to me that OCSPvalid is trying to do the
> > same thing as OCSP.
>
> They're not. DPV proposes a standard extension OID and a corresponding
> semantic for use by existing 2560 environments who wish to
> build into their
> existing user base a means for delegated path validation.
>
> > So why is there such a strong interest in
> > doing it as an extension to OCSP
>
> Because from a bits-on-the-wire perspective, it's trivial.
> It's just an OID
> after all, and based on existing hooks in an existing RFC. Sure,
> imlementing on a server the path validation and its corresponding path
> discovery process is a pain. But that's a sunk cost no
> matter how we go.
>
> But A 2560 server that implements signed requests should
> already have the
> path discovery and path validation logic in place anyway so
> it's simply a
> matter of linking the two with a bit of glue logic. Further,
> 2560 servers
> that rely on the acquisition of CRLs to supply
> BasicOCSPResponse would (I
> presume) reject CRLs that fail to validate against a full
> path check. They
> too would (or should) have in place the raw materials
> necessary to path
> discovery and path validation.
>
> So implementing DPV is nothing more than a week's worth of
> glue logic and
> some test cases. And it's the testing, not code development, that'll
> consume the bulk of that resource.
>
> > I believe it will actually
> > cause more confusion than clarification, where when somebody
> > says they support OCSP and another person wants to use OCSP, there
> > is no guarantee that they are talking about the same thing.
>
> We'd be happy to hear from you on a technical basis how the
> mechanisms we
> propose fail to address this concern. We could have
> overlooked something.
>
> >
> >
> > Ambarish
> >
> >
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect
> 650.567.5457
> > ValiCert, Inc.
> ambarish@valicert.com
> > 339 N. Bernardo Ave.
> http://www.valicert.com
> > Mountain View, CA 94043
> >
> >
> >
>
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21371 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 13:20:54 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA26710; Mon, 13 Nov 2000 13:23:56 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <WZAJNW39>; Mon, 13 Nov 2000 13:27:44 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4B00B6F@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: "'Ambarish Malpani'" <ambarish@valicert.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
Date: Mon, 13 Nov 2000 13:23:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Ambarish:
As a I noted earlier, you need to split out the OCSPv2 draft from the DPV
and DPD drafts. OCSPv2 simply expands on certificate identification
mechanisms into well-known use cases while preserving backwards
interoperability with existing 2560-compliant implementations. There's a
few other tweaks but that's the core of it. I have embedded more specific
comments below.
With respect,
Mike
> -----Original Message-----
> From: Ambarish Malpani [mailto:ambarish@valicert.com]
> Sent: Friday, November 10, 2000 1:42 PM
> To: 'ietf-pkix@imc.org '
> Subject: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
>
>
>
>
> Here are some of my thoughts on why I think SCVP is the right
> way to go ahead with remote path processing (RPP), rather than
> creating a new version of OCSP (OCSPv2) and then defining OCSPpath
> and OCSPvalid.
>
> Issues with OCSPv2
> ------------------
> - It causes uncertainity and concern about OCSP, even though there
> aren't really any problems with the protocol itself
There's no uncertainty that RFC2560 has been approved by PKIX and the IESG.
The only uncertainty is whether or not the WG believes there's sufficient
benefit to have certID (and a few other tweaks) fixed before RFC2560
progresses further down the standards track.
> - It will cause a bunch of interoperability issue with OCSP for
> certificate status checks, because now you can identify a
> certificate in many different ways
The thing is, people are doing this already for a variety of reasons, so
OCSPv2 isn't *causing* anything. Rather, it's responding to well-known
needs.
> - The semantics of what a server is required to do for a plain
> OCSP request are unclear - does it need to check the expiry of
> the certificate, what about the signature, etc on the cert?
Please clarify if you're speaking to RFC 2560, OCSPv2 or DPV/DPD.
> - It is unclear to me that the right thing to do is to change a
> stable protocol just to add a bunch of new functionality, that
> doesn't really do anything more for the base protocol.
OCSPv2 does not create new functionality. It standardizes the basis for
additional code development towards delivering 2560-based functionality into
well-known use cases.
> - If we go this route, we will take a lot longer to actually
> reach a usable spec for RPP, because our first 12 months will
> be spend debating the changes to OCSP
SCVP's XML perspective may (should?) take into consideration all the variant
opinions regarding the integration of XML with PKI and ASN.1. Given the
abundance of recent WG comments, the timeframe is predictably the same
either way.
> - I would actually like the current OCSP, with some minor
> clarifications and changing of the required signature algorithm
> to RSA (from DSA), to continue on the standards track, we have
> actually had a reasonable amount of interop testing on it
It's my intent that the OCSPv2 draft will lead to an informed technical
debate on all issues relevant to RFC2560's transition in status. Your
preference for RSA as a SHALL vs. DSA as a SHOULD is noted.
>
> Issues with this approach
> -------------------------
> - It is very unclear to me that OCSPvalid is trying to do the
> same thing as OCSP.
They're not. DPV proposes a standard extension OID and a corresponding
semantic for use by existing 2560 environments who wish to build into their
existing user base a means for delegated path validation.
> So why is there such a strong interest in
> doing it as an extension to OCSP
Because from a bits-on-the-wire perspective, it's trivial. It's just an OID
after all, and based on existing hooks in an existing RFC. Sure,
imlementing on a server the path validation and its corresponding path
discovery process is a pain. But that's a sunk cost no matter how we go.
But A 2560 server that implements signed requests should already have the
path discovery and path validation logic in place anyway so it's simply a
matter of linking the two with a bit of glue logic. Further, 2560 servers
that rely on the acquisition of CRLs to supply BasicOCSPResponse would (I
presume) reject CRLs that fail to validate against a full path check. They
too would (or should) have in place the raw materials necessary to path
discovery and path validation.
So implementing DPV is nothing more than a week's worth of glue logic and
some test cases. And it's the testing, not code development, that'll
consume the bulk of that resource.
> I believe it will actually
> cause more confusion than clarification, where when somebody
> says they support OCSP and another person wants to use OCSP, there
> is no guarantee that they are talking about the same thing.
We'd be happy to hear from you on a technical basis how the mechanisms we
propose fail to address this concern. We could have overlooked something.
>
>
> Ambarish
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect 650.567.5457
> ValiCert, Inc. ambarish@valicert.com
> 339 N. Bernardo Ave. http://www.valicert.com
> Mountain View, CA 94043
>
>
>
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20554 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 12:48:16 -0800 (PST)
Received: from tsg1 ([12.72.0.56]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001113205436.VMHQ13638.mtiwmhc24.worldnet.att.net@tsg1> for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 20:54:36 +0000
Message-ID: <014201c04db6$919c9a80$020aff0c@home.glassey.com>
From: "todd glassey" <todd.glassey@worldnet.att.net>
To: <ietf-pkix@imc.org>
Subject: Fw: FW: Fun PKI Article from Down Under
Date: Mon, 13 Nov 2000 13:13:21 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
fyi -
----- Original Message -----
From: "Toby Brown" <toby@o2exchange.com>
To: <ST-ISC@MAIL.ABANET.ORG>
Sent: Monday, November 13, 2000 8:37 AM
Subject: FW: Fun PKI Article from Down Under
> In case people haven't seen this one.
>
>
>
> Public Key Infrastructure: An Artifact Ill-Fitted to the Needs of the
> Information Society
> Roger Clarke
>
> Principal, Xamax Consultancy Pty Ltd, Canberra
>
> Visiting Fellow, Department of Computer Science, Australian National
> University
>
> Prepared for submission to the 'IS in the Information Society' Track of
the
> Euro. Conf. in Inf. Syst. (ECIS 2001), Bled, Slovenia, 27-29 June 2001
>
> Version of 9 November 2000
>
> © Xamax Consultancy Pty Ltd, 2000
>
> This document is at
> http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html
>
>
> --------------------------------------------------------------------------
--
> ----
>
> Abstract
> It has been conventional wisdom that, for e-commerce to fulfil its
> potential, each party to a transaction must be confident in the identity
of
> the others. Digital signature technology, based on public key
cryptography,
> has been claimed as the means whereby this can be achieved. Digital
> signatures do little, however, unless a substantial infrastructure is in
> place to provide a basis for believing that the signature means something
of
> significance to the relying party.
>
> Conventional, hierarchical PKI, built around the ISO standard X.509, has
> been, and will continue to be, a substantial failure. This paper examines
> that form of PKI architecture, and concludes that it is a very poor fit to
> the real needs of cyberspace participants. The reasons are its inherently
> hierarchical and authoritarian nature, the unreasonable presumptions it
> makes about the security of private keys, a range of other technical
> defects, confusions about what it is that a certificate actually
> authenticates, and its inherent privacy-invasiveness. Alternatives are
> identified.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> Contents
> 1. Introduction
> 2. The Perceived Need
> 3. Conventional Technology
> 3.1 Digital Signatures
> 3.2 Public Key Infrastructure
> 3.3 The X.509v3 Standard
> 3.4 The Hierarchical Model of Trust and Liability
> 4. Private Key [In]Security
> 5. Other Technical Weaknesses in X.509
> 6. What Assurance Does an X.509v3 Certificate Actually Provide?
> 7. Privacy Concerns
> 8. Alternative Models of Trust
> 8.1 PGP's 'Web of Trust'
> 8.2 SPKI/SDSI
> 8.3 Stefan Brand's Alternative Certificates
> 8.4 Reputation and Brand
> 8.5 Nyms
> 8.6 Trust Management
> 9. Conclusions
> References
>
> --------------------------------------------------------------------------
--
> ----
>
> 1.Introduction
> There has been a perception that the adoption of e-commerce has been
> significantly slowed because, in cyberspace, buyers don't trust
> unidentifiable sellers. Digital signatures, and the mechanism that support
> them, Public Key Infrastructure (PKI), have been touted as the solution to
> the problem. Despite quite some years of development, however, each step
> forward with PKI seems to create a set of new sub-problems.
>
> Meanwhile, a range of other impediments to net-consumer trust of
cyberspace
> merchants has been identified (Clarke 1999c). And PKI has been criticised
on
> both technical grounds (e.g. Ellison and Schneier 2000) and privacy
grounds
> (e.g. Greenleaf & Clarke 1997). This paper examines PKI from a broader
> perspective, by relating its features to what the Information Society
really
> needs.
>
> The paper commences by stating the problem that was originally perceived,
> and describing the currently conventional technology that has been
harnessed
> to solve it. Major problems with that solution are then identified, in the
> areas of key insecurity, other technical deficiencies, its failure to
> provide useful assurances to net-users, and its privacy-invasiveness. The
> paper concludes by explaining the critical nature of 'nyms', and a brisk
> assessment of alternative approaches that hold out greater prospect for
> meeting the needs of Information Society.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 2. The Perceived Need
> The commercial potential of the Internet became apparent only in the
> mid-1990s. Wired Magazine, launched in October 1994, claimed (with
> justification) that its Hotwired venture was the first commercial
web-site.
>
> >From an early stage, the conventional wisdom was that e-commerce, in
> comparison with purchasing in a physical location like a shop, lacks the
> important comfort factor of seeing who you're dealing with, or at least
> being able to see the merchant's physical 'foot-print'. It was therefore
> postulated that successful commerce on public networks would be dependent
on
> some other means of establishing trust.
>
> A leap was then made to the conclusion that trust would need to be based
on
> a mechanism for the identification of parties who deal on the net,
> supplemented by authentication mechanisms to test the assertions of
> identity. A recent expression of this is that "Fundamentally, electronic
> commerce involves the use of remote communications and therefore
> necessitates all parties involved to authenticate one another ...
[because]
> the parties will not at the time of transacting have face to face
dialogue"
> (McCullagh & Caelli, 2000).
>
> Moreover, the demand for identity was presumed to be two-sided, i.e. not
> only would the merchant or services-provider identify themselves to the
> consumer but consumers would also identify themselves to sellers. It is
> unclear whether this was a conscious assumption, and if so whether it was
> based on an analysis of merchant behaviour, or was merely a pretext for
the
> creation of exploitable trails of consumer behaviour. Either way, it
> represents a significant compromise of what have hitherto been to a
> considerable extent anonymous transactions.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 3. Conventional Technology
> This section provides a brief overview of the key technologies that have
> enabled engineers to address the perceived problem described above.
>
> During the 1980s, public key (or 'asymmetric') cryptography had emerged.
> Public key cryptography involves two related keys, referred to as a
> 'key-pair', one of which only the owner knows (the 'private key') and the
> other which anyone can know (the 'public key'). Because only one party
needs
> to know the private key, it does not need to be transmitted between
parties,
> and hence it need never be exposed to the risk of interception. Knowledge
of
> the public key by a third party, on the other hand, does not compromise
the
> security of message transmissions (Diffie & Hellman 1976, Schneier 1996).
> For a tutorial treatment, see Clarke 1996).
>
> The following sub-sections introduce the key application of 'digital
> signatures', and then the infrastructure on which they depend. The
dominant
> form of public key infrastructure is then outlined and interpreted.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 3.1 Digital Signatures
> Digital signatures are a particular application of public key
cryptography.
> A digital signature is a block of data that is generated from a message
> prior to its despatch, and is appended to it. The block is prepared by a
> two-step process:
>
> a 'message digest' is created by processing the actual message using a
> pre-agreed one-way hash algorithm; and
> this message digest is encrypted with the sender's private key.
> The recipient re-creates the message digest from the message that they
> receive, uses the sender's public key to decrypt the digital signature
that
> they received appended to the message itself, and compares the two
results.
> If they are identical, then:
>
> the content of the message received must be the same as that which was
sent
> (assuring message content integrity);
> the message can only have been sent by the purported sender (providing a
> means of authentication); and
> the sender cannot credibly deny that they sent it (addressing the need for
> non-repudiatiability of messages).
> This paper concerns itself with only the second of these, the use of a
> digital signature to authenticate something about the message-sender.
>
> Digital signatures were naively presumed by many people to provide
> unqualified assurance. In practice, however, the effectiveness of the
> mechanism is dependent on a number of conditions, in particular:
>
> a third party must have checked that the private key is in the possession
of
> the appropriate party;
> that third party must be trustworthy;
> the private key must be subject to strong security measures, such that no
> other party can ever gain access to it or invoke it;
> the public key used must be the appropriate one, and not one provided by
an
> imposter; and
> a number of infrastructural elements must all be in place, functioning
> effectively, and their security not compromised.
>
> --------------------------------------------------------------------------
--
> ----
>
> 3.2 Public Key Infrastructure
> Digital signature schemes depend on the public key of the message-sender
> being available to the recipient. The most practicable methods of
achieving
> this are:
>
> senders can include their public keys in each message;
> senders can store them at a site that is readily accessible (e.g. using
FTP
> or HTTP); or
> public keys may be stored in one or more centrally managed directories,
> enabling each party to an exchange to look up the public key of the other
> party.
> All of these approaches are subject to 'spoofing', i.e. an imposter can
send
> a message that includes a public key, or store a public key in a
directory,
> and thereby fool the other party into thinking the message came from a
> particular person or organisation.
>
> To address this risk, the concept was created of a 'certificate' that
> attests to the fact that that public key is associated with a particular
> party. (The technical literature uses the term 'is bound to' rather than
'is
> associated with'. This implies to the normal reader a far stronger kind of
> association than the technique actually warrants).
>
> More precisely, a 'certificate' is a digitally signed, structured message
> that asserts an association between specific data and a particular public
> key. An 'identity certificate' is then a particular class of certificate
> that associates a particular identifier with a particular public key. (It
> will be argued later in this paper that the term 'identifier' should
really
> be replaced by 'nym'). Regrettably, most of the literature uses the term
> 'certificate' to refer to both of these concepts, often in the same
> sentence, despite the fact that the differences are extremely important.
>
> According to conventional thinking, a certificate needs to be created by a
> trusted 'public key certification authority' (CA). A CA digitally signs
each
> certificate using its own private key. In most schemes, that certificate
is
> provided to the party that claims the particular key to be its own, who
> includes it in the messages that they send. A message with a CA's
> certificate attached therefore functions in a manner analogous to a letter
> applying for a job being accompanied by a letter from a referee attesting
to
> something about the applicant, such as their identity, their good
character,
> their experience, or their qualifications.
>
> A CA needs to undertake some form of authentication process in order to
> satisfy itself that the claimed association actually exists. A
conventional
> approach is to depend on the services of a Registration Authority (RA),
such
> as a Post Office. A comprehensive process would require the person with
whom
> the key is to be associated to undertake all of the following:
>
> present themselves at the RA's premises;
> provide physical evidence of the characteristic claimed. This would
> typically involve 'photo-id', and documentary evidence of (for example)
age,
> qualifications and/or professional membership, supported by a documentary
> trail evidencing the use of the relevant identifier(s) over a period of
time
> (including, for example, marriage certificate or deeds poll);
> provide the public-key;
> provide evidence that they are the holder of the private-key (e.g. by
> signing a message in the presence of the RA);
> provide evidence that they have the private-key secure;
> nominate a contact-point; and
> nominate a delivery-point for the certificate.
> Because of the effort and expense involved, the onerousness and the
> demeaning nature of the process, schemes generally compromise on these
> requirements. Many ignore them almost entirely by, for example, depending
on
> some prior relationship between the person and the RA or CA.
>
> CAs deflect attention from the critical weaknesses of their registration
> processes by drawing attention to the physical and electronic security of
> the facilities that they use to generate the certificate.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 3.3 The X.509v3 Standard
> The dominant standard at present is the family of CCITT X.500 standards,
in
> particular X.509 (X.509 1988, Housley et al. 1999). The current version of
> X.509 is number 3, usually referred to as X.509v3, which was finalised in
> 1997. A set of standards, dubbed PKIX, enables use of X.509 approaches
> within the web-context (W3C 2000). Guidance has been provided by texts
such
> as Ford & Baum (1997), Adams & Lloyd (1999) and Austin et al. (2000).
>
> Ellison (1997) describes the history this way: "the X.500 proposal was
> published [in the late 1980s]. It was to be a global directory of named
> entities. To tie a public key to some node or sub-directory of that
> structure, the X.509 certificate was defined. The Subject of such a
> certificate was a path name indicating a node in the X.500 database - a
> so-called 'Distinguished Name'. The X.500 dream has effectively died but
the
> X.509 certificate has lived on. The distinguished name took the place of a
> person's name and the certificate was called an 'identity certificate',
> assumed to bind an identity to a public key ...". In short, X.509 was the
> hammer that came to hand when the nail was discovered.
>
> All forms of PKI necessarily involve some degree of intrusiveness, in
order
> that sufficient quality can be achieved. Conventional PKI, built around
> X.509v3 certificates, is especially severe. Implementations commonly have
> many of the following features:
>
> a single key-pair per person;
> a 'distinguished name' that is unique across a name-space that is in
> principle vast, and in practice large, and that denies the opportunity for
> pseudonyms;
> a certificate that expressly claims to 'bind' the key to a person;
> little or no choice in the manner in which the key-pair is generated;
> in many cases, generation of the key-pair outside the control of the
person
> concerned, with the result that the private key is ab initio in someone
> else's possession;
> issuer-ownership of the key-pair, with individuals merely licensed to use
> it;
> little or no choice as to what token (such as a diskette or chip-card) is
> used to store and carry the private-key and certificates;
> little or no choice as to who will issue the token;
> issuer-ownership of the token, with individuals merely licensed to use it;
> little or no choice in the organisation from which the individual acquires
a
> certificate; and/or
> a hierarchy of certificate authorities.
> Current X.509v3 certificates go so far as to permit an agent of an
> organisation to protect their personal identity through the use of a
> role-title; but they actually preclude an individual (referred to as a
> 'residential person') from having that capability. Moreover, some
> implementations may preclude a residential person from possessing multiple
> personal key-pairs, even though the same person is permitted to possess
> multiple key-pairs for organisations that they represent.
>
> Some schemes even involve the key-pair generation process being
compulsorily
> performed by some organisation on behalf of individuals, and compulsory
> storage (or 'escrow') of the private key.
>
> X.509v3 certificates provide a limited means for communicating attributes,
> within the primary certificate or through the creation of secondary
> certificates which may attest to one or more characteristics of the
> individual. But the attributes are inherently linked to and dependent on
the
> primary certificate, which bears the individual's identifier.
>
> Given the nature of X.509v3-based PKI, individuals, including not only
> consumers, but also employees and contractors, especially those in
sensitive
> occupations, are justified in having serious concerns about schemes of
this
> nature being inflicted upon them.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 3.4 The Hierarchical Model of Trust and Liability
> X.509v3-based PKI is inherently hierarchical. This is because trust in the
> CA is not automatic, and each layer of CAs needs to be attested to by some
> superior layer. Conventional PKI therefore depends on one partly but not
> entirely trusted third party, which in turns depends on another such
partly
> but not entirely trusted third party, which needs to be attested to be
some
> further superior layer. This results in an unholy spiral up to some
mythical
> authority in which everyone is assumed to have ultimate trust. Trust in
the
> real world has never worked like that, and trust in cyberspace won't
either.
>
> Such shemes can also be readily argued to be authoritarian in nature
(Clarke
> 1994b). For example, there is an intrinsic assumption that all parties
> providing certificates are required to disclose their identity, even if
the
> only functional need is to communicate eligibility (e.g. age, their age,
> qualifications, or agency relationship with a principal).
>
> The further assumption is made that the 'distinguished name' has to be
> unique within the 'name-space'. This precludes the second and subsequent,
> say John Robinson, from using their own name without some kind of
qualifier.
> It also provides no basis for individuals to use alternative identifiers,
> and implicitly denies individuals the capability to have and use multiple
> key-pairs, and multiple certificates. The engineers who created the X.509
> standard appear to have been blithely unaware that multiple identities per
> person are entirely legal in many jurisdictions, including those whose
legal
> systems derive from the United Kingdom (Clarke 1994c).
>
> A further feature of schemes of this kind is an implicit assumption that a
> CA will provide some form of warranty and/or indemnity to accompany the
> assurance, i.e. to recognise financial liability in the event that the
> assurance transpires to be incorrect, and that a party's reasonable
> dependence on the assurance resulted in economic cost. In practice,
however,
> CAs are very eager to phrase what are commonly termed 'Certificate Policy
> Statements' in such a manner that they minimise their exposure.
>
> With some qualifications, X.509v3 architectures are designed work within
an
> 'absolute trust' view of security, rather than a 'risk-management'
approach.
> On the other hand, actual implementations tend to compromise this,
sometimes
> severely. In particular, most operational schemes have only one layer of
CA,
> and the basis on which each recipient of a message is supposed to trust
> those CAs is a 'self-signed' certificate, i.e. blind trust in the company,
> its intentions, and its procedures.
>
> For whatever reason, the major implementations of X.509-based PKI, such as
> that based on the Verisign certificates embedded in commercially-available
> web-browsers, are at best 'relaxed' applications of formal X.509
standards,
> and hence the current PKI is even less meaningful than that which would be
> feasible if it was applied as intended.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 4. Private Key [In]Security
> Underlying digital signatures and PKI is the assumption that the holder of
a
> private key will be able to ensure its security. During the 1999-2000
> period, corporate servers have been subject to a rash of electronic
> break-ins. The ease with which many of these have been performed have
> demonstrated the serious inadequacy of the precautions taken by
> organisations of all kinds and all sizes.
>
> To date, it does not appear that private keys have been a particular
target
> of the crackers. There are likely to have been multiple reasons for this,
> not least the relatively small usage of private keys, and the fact that
> there have been plenty of more attractive items of data to aim for. As and
> when private digital signature keys attract more attention, it is
reasonable
> to expect that more attacks will be made, and that many corporate keys
will
> be compromised.
>
> Conventional PKI also assumes that consumers and citizens will have, and
> will need to use, private keys. The author has recently supervised a
project
> to examine the scope for consumers to protect their keys within 'commodity
> workstations', such as Windows, MacOS and Linux machines directly
connected
> to the Internet via commercial Internet access service providers (Kaiser
> 2000). In general, commodity workstations have very limited security
> features within the available hardware or systems software. There are few
> products available that would enable consumers to graft security features
on
> to their work-and-play facilities, and such products as exist require
> considerable expertise to install and configure.
>
> Private keys are susceptible to a vast array of risks, both of capture,
and
> of invocation without the authority of, or even knowledge of, the
> consumer/citizen. As Ellison & Schneier (2000b) put it: "Alice's digital
> signature does not prove that Alice signed the message, only that her
> private key did. When writing about non-repudiation, cryptographic
theorists
> often ignore a messy detail that lies between Alice and her key: her
> computer. If her computer were appropriately infected, the malicious code
> could use her key to sign documents without her knowledge or permission.
> Even if she needed to give explicit approval for each signature (e.g., via
a
> fingerprint scanner), the malicious code could wait until she approved a
> signature and sign its own message instead of hers. If the private key is
> not in tamper-resistant hardware, the malicious code can just steal the
key
> as soon as it's used".
>
> In short, the context of use of digital signatures is such that very
little
> confidence can be placed in the meaningfulness and reliability of
> authentication processes that depend on them.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 5. Other Technical Weaknesses in X.509
> A range of other difficulties have been identified (Ellison & Schneier
> 2000).
>
> For example, there are difficulties in detecting that a private key has
been
> compromised, and after that there are difficulties in implementing an
> effective revocation process. This is especially serious if retrospective
> revocation is permitted (i.e. notification to a set of recipients that a
> private key had been compromised since some past time, and that the sender
> reserves the right to repudiate transactions signed after that time).
> Time-stamping is a critical aspect of revocation processes; but it is not
an
> assured, secure service.
>
> Another issus is that X.509-based PKI assumes either that there is a
single
> global name-space (i.e. world government, and a single, unique identifier
> imposed on every citizen of the world), or that multiple name-spaces
exist,
> but that they inter-operate (and that each regional authority imposes a
> single, unique identifier on every person under their jurisdiction).
>
> Ellison (1996) long ago concluded that "if the bond between key and person
> is broken, no layer of certificates will strengthen it. On the contrary,
in
> this case certificates merely provide a false sense of security to the
> [recipient]".
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 6. What Assurance Does an X.509v3 Certificate Actually Provide?
> The final issue strikes at the very heart of PKI. The presumption made by
> most commentators is that a certificate provides the message-recipient
with
> assurance that the sender was indeed who the sender purports to be. But
that
> is not the case.
>
> The concept of 'authentication' has been seriously misunderstood by the
> designers of X.509-based PKI. Authentication is a process whereby a degree
> of confidence is established in the truth of an assertion. There are many
> kinds of assertions that can be the subject of authentication processes.
> Among them are assertions of the form 'this artefact has a value
equivalent
> to so much of a particular currency', and 'the sender of this message has
a
> credential that attests to their eligibility to perform a particular
> function'.
>
> In order to discuss the real meaning of a certificate, some definitions of
> terms are needed:
>
> an entity is a real-world thing. A pallet, a package and a widget are
> examples of entities that are generally not relevant in the current
context;
> whereas a person, an organisation, and an artefact that is capable of
taking
> a relevant action (e.g. a hardware-server, a software-server, a
> hardware-client, a software-client, a software agent) are of direct
> relevance. An entity is not capable of being directly expressed as data;
> an identity is a defined and specific instance of a class of entity (e.g.
a
> particular person, organisation, computer or software process). Each
entity
> has precisely one identity. An identity is not capable of being directly
> expressed as data;
> an identifier is a data-item or group of data-items which reliably
> distinguish the identity of an entity. An identity may have many
identifiers
> (i.e. the mapping is 1:n). (Note that, in most of the literature relating
to
> digital signatures, certificates and PKI, the term 'name' is used
variously
> to refer to a specific kind of identifier and to refer to identifiers
> generally).
> One (but only one) kind of assertion that may be subject to authentication
> is 'the sender of this message is the (or an) entity that uses a
particular
> identifier'.
>
> But a certificate doesn't attest to that. It does attest that:
>
> a particular message was generated by an artefact that had available to it
a
> particular key; and
> the CA that provided the certificate has, at some time in the past, had
> grounds for believing that private key to be associated with a particular
> entity.
> Depending on the registration process that was applied, it may also attest
> that:
>
> the CA that provided the certificate has, at some time in the past, had
> grounds for believing that the entity had some kind of right to use that
> identifier, or had used that identifier in the past; and
> the CA that provided the certificate has, at some time in the past, had
> grounds for believing that the entity had access to the appropriate
private
> key.
> A certificate provides no assurance about whether:
>
> the private key was originally available to other entities as well as the
> entity to which it purports to be 'bound';
> the private key is now available to other entitiess as well as the entity
to
> which it purports to be 'bound';
> the private key invocation that gave rise to a particular message was
> performed with the entity's free and informed consent.
> Morover, such assurance as a certificate provides is qualified by terms
> dictated by the CA's lawyers; and very limited recourse is available
should
> the assurance be wrong.
>
> McCullagh & Caelli (2000) argue that "In the legal sense an alleged
> signatory to a document is always able to repudiate a signature that has
> been attributed to him or her. The basis for a repudiation of a
traditional
> signature may include:
>
> The signature is a forgery;
> The signature is not a forgery, but was obtained via:
> Unconscionable conduct by a party to a transaction;
> Fraud instigated by a third party; [or]
> Undue influence exerted by a third party.
> "There is a strong movement to legally reverse the onus of proof for
digital
> signatures. The position being promoted is for the alleged signatory to
have
> the onus of proof in establishing that he or she did not digitally sign a
> given document. ... It is submitted that the law should not in the
> electronic commerce environment alter this position as regards to the
legal
> rights of parties to repudiate a digital signature".
>
> McCullagh and Caelli conclude that "Without a trusted computing system,
> neither party - the signer or the recipient - is in a position to produce
> the necessary evidence to prove their respective case". In short, an
X.509v3
> PKI is of no use, unless conditions are satisfied that manifestly are not
> satisfied.
>
> The inescapable conclusion is that the contemporary implementation of PKI
in
> the Internet context is a complete waste of time and effort, and
represents
> nothing more than a gesture towards the need for security.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 7. Privacy Concerns
> The previous sections have focussed mainly on technical inadequacies, but
> mentioned privacy in passing. This section summarises the privacy impact
of
> conventional digital signatures and PKI. Greenleaf & Clarke (1997)
> identified a wide range of threats, and categorised them as follows:
>
> Private Keys
> Private key generation. To ensure that the private key is never outside
the
> possession of the user, it needs to be generated entirely under the user's
> control;
> Private key storage and backup. To ensure that the private key is never
> outside the possession of the user, it needs to be securely stored and
> backed-up;
> Private key escrow. Because of the need to ensure that the private key is
> never outside the possession of the user, any form of escrow of digital
> signature private keys is inimical to the very concept of PKI;
> Private key access. Because of the need to ensure that the private key is
> never outside the possession of the user, private digital signature keys
> need to be exempt from court orders and search warrants;
> Private key revocation. Revocation needs to be very carefully undertaken
> (because, by definition, doubt has been thrown on the authenticity of a
> message signed using that private key); yet it needs to be very quickly
> undertaken (because of the risk of masquerade and fraud in the interim);
> Public Keys
> Certification identification requirements. Presentation at a Registration
> Authority in order to seek a certificate is onerous, and may involve
> intrusive demands for documents and even biometrics;
> Registers of public keys and/or certificates. Any such register that may
be
> established inevitably contains sensitive personal data. Moreover, it
> creates a serious risk of the public key or certificate id becoming used
as
> a multi-purpose identifier for individuals, with all the
> privacy-invasiveness that multi-purpose identification entails (Clarke
> 1994c, 1997);
> Certificate Revocation Lists (CRLs). To the extent that it might become
> normal to check the CRL as part of the processing of a transaction, the
CRL
> logs would become a centralised and highly intensive trail of a person's
> e-activity. Moreover, the CRL represents an opportunity for an authority
to
> cancel a person's cyber-identity;
> Consequential Privacy Implications
> Increased expectations of identification. The existence of a means whereby
> senders can identify themselves might well lead to an increased level of
> expectation that they do so in all forms of communication. This would
break
> down long-established and vital traditions of anonymity and pseudonymity;
> Chip-storage as a means of carriage of the private key. Because of the
need
> for secure storage of the private key, individuals could be coerced into
the
> acquisition and use of some form of chip-carriage mechanism. This would
> currently most likely be a card, but many other carriers are feasible,
> including direct implantation into the person (Clarke 1997);
> Central storage of biometrics. One means of preventing persons other than
> the owner of the private key from invoking it is to protect it with a
> biometric. Most biometric schemes to date involve central storage, which
is
> an enormous risk to individuals, because of the potential for the
biometric
> to be used as a basis for masquerade (Clarke 2000).
> Some of these problems are features of conventional PKI schemes that could
> be avoided or designed around. Many, however, are direct implications of
the
> nature of the X.509 architecture and certificate design.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8. Alternative Models of Trust
> Conventional PKI are ineffectual and privacy-invasive. Fortunately, there
> are other ways to address the need for trust in marketspaces. Their
> discovery depends in part on re-definition of the problem.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.1 PGP's 'Web of Trust'
> The 'web of trust' approach is intrinsic to the longstanding alternative
> product Pretty Good Privacy (PGP) - ( (Zimmerman 1995, Garfinkel 1995,
> Bacard 1995, Stallings 1995). This avoids the need for professional CAs,
> because certificates can be issued by anyone. Fault-tolerance is achieved
by
> depending on multiple certificates, probably with varying weightings
> assigned to them by the evaluator, on the basis of the degree of trust
they
> place in the person who provided the certificate. The 'identifier' used is
> the email-address. This is unique, simply because of the manner in which
> domain-names are allocated, and aliases and user-names are assigned.
>
> The approach requires message-recipients to consider the extent to which
> they really need assurance, and confront the simple fact that all
assurance
> is relative rather than absolute. The PGP concept is non-deterministic and
> uncomfortable, but it reflects the reality of social and economic
activity.
>
> This finds echoes in the works of some theorists. For example, Maurer
(1996)
> highlights the fragility of the assumption that the determination of trust
> is deterministic and computable on the basis of certificates, and
discusses
> the alternative of a probabilistic approach to the problem. This is
related
> to the naive military concept of 'absolute trust' and the less naive, more
> realistic and less expensive alternative of a 'risk-managed' approach to
> security issues.
>
> Criticisms have been levelled at PGP's specific implementation of the 'web
> of trust' notion. But arguments have been pursued for the concept to be
> broadened and applied more generally (Grossman 2000).
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.2 SPKI/SDSI
> Another standardisation process is that which grew out of Simple Public
Key
> Architecture (SPKI) - (Ellison 1996, IETF 1997-, Wang 1998, Ellison 2000).
> The momentum has now shifted to a parallel initiative, the Simple
> Distributed Security Infrastructure (SDSI) - (Rivest & Lampson 1996, SDSI
> 1996, Ellison 2000). The two approaches are in the process of being
> harmonised.
>
> The key element of SDSI is that the X.509 nirvana of a single, global
> name-space has been abandoned. With it, the presumption has been removed
> that 'name' (or, better expressed, 'identifier') is reliably bound to a
> particular entity. In effect, the certificate binds a public key (and
hence
> a key-pair) to an entity that only the CA knows. No warranties are
provided
> by the CA to the recipient of the message as to who the keyholder is.
>
> Attributes are associated with public keys, not with identities of
> real-world entities. Hence, for example, a recipient can be assured that a
> particular message was provided by a medical practitioner, or a person
over
> 18, or over 65, or in possession of power of attorney for a company for
> purchases up to $10,000; but the certificate is silent about the identity
of
> the person who is using the key (Ellison 2000).
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.3 Stefan Brand's Alternative Certificates
> Brands (2000) proposes a different conception and implementation of
digital
> certificates, such that privacy is protected without sacrificing security.
> The validity of such certificates and their contents can be checked, but
the
> identity of the certificate-holder cannot be extracted, and different
> actions by the same person cannot be linked. Certificate holders have
> control over what information is disclosed, and to whom.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.4 Reputation and Brand
> Trust may be based on reputation, by which is meant 'generally held'
> positive opinion about an entity.
>
> There are several ways in which 'generally held' opinion can arise. These
> include:
>
> performance-based reputation, whereby an entity is active within a
community
> for some time, and comes to be perceived by participants in that community
> to have positive characteristics, and hence to be trustworthy;
> social-network-based reputation, whereby entities that are already known
> within an community introduce the entity, in effect attesting that 'yes,
> this entity is known to me';
> an entity may use advertising and public relations techniques to establish
> or embellish a 'brand'; and
> an entity can seek to engender trust in itself by using a 'meta-brand',
such
> as a seal of approval from some organisation that projects advertising and
> public relations on behalf of its clients, e.g. TRUSTe and WebTrust.
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.5 Nyms
> An earlier section argued that the privacy impacts of PKI are severe. It
is
> critical that any assurance mechanism that is implemented on the Internet
be
> at least tolerant, and even actively supportive, of anonymity and
> pseudonymity. These concepts, examined in Clarke (1993), Clarke (1994) and
> Clarke (1999), are critical to ensure that the advent of cyberspace does
not
> mean the death of private space.
>
> If PKI is to serve the needs of information society, the focus must be
moved
> away from identities of individuals. One direction of importance is to
> address the question of agents, both other humans and artefacts, and
> mechanisms for effective delegation to them.
>
> Another vital set of needs is for:
>
> roles to be supported without necessarily declaring the identity of the
> individual performing them;
> attributes to be able to be communicated without being linked to identity;
> and
> persistent relationships to be enabled even though either or both parties
> are anonymous.
> These objectives can be achieved through the application of the concept of
a
> 'nym'. This is the pseudo-identity that arises from anonymous and
> pseudonymous dealings (McCullagh 1996-, Clarke 1999).
>
> An earlier section offered definitions for the terms 'entity', 'identity'
> and 'identifier'. Two further terms require explanation:
>
> a role is a particular presentation of an entity. An entity may have many
> roles; and a role may be associated with more than one entity (i.e. the
> mapping of role to entity is m:n). A role is not capable of being directly
> expressed as data;
> a nym is a data-item or group of data-items which reliably distinguishes a
> role. However, because a role is not reliably related to an entity, there
is
> no reliable mapping between a nym and the underlying entity or entities
> (i.e. the mapping is m:n, but is not determinable).
> Nyms are not mere imagination: technologies exist that enable them. See
EPIC
> (1997-) and Clarke (1999a). Moreover, it may be very important to the
future
> of e-commerce that infrastructure support nyms, and that people adjust to
> their existence and nature. As Ellison (1997) argued: "The [U.S. House
> Hearing] asked 'Do you know who you are doing business with?'. Before
> answering that question, one should really answer the two questions: 'Do
you
> need to know who you are doing business with?', and 'Can you know who you
> are doing business with?'".
>
> Nyms are in practice replacing identifers. Leaving aside services /
> protocols such as IRC, MUDDs and ICQ:
>
> PGP depends on email-addresses, which are not formally linked to entities,
> and which may have any of a 1:1 relationship with a single person, or 1:n
> (multiple people may share the same address), or n:1 (a person may have
> multiple addresses); or indeed m:n (multiple accounts may be used by
> multiple people);
> with SPKI/SDSI-based PKI, an 'identifier' is not reliably bound to a
> particular entity, because the certificate relates to the key, and says
> nothing reliable about the key-holder; and attributes are associated with
> the key, not with the identity/ies of the real-world entity/ies who use
the
> key. SPKI's originator, Carl Ellison draws attention to the privacy
dangers
> of using any identifier consistently, because the action provides the
means
> whereby the data trails the person leaves behind can be collated: "The
real
> solution is for the user to generate multiple key pairs and use them for
> carefully walled-off purposes" (2000a). These are, of course, nyms; and
> Stefan Brands' certificates are expressly anonymous.
> Any approach to inculcating trust in marketspaces will need to implement
> persistent nyms at least for the consumer side of the transaction.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 8.6 Trust Management
> An approach that avoids and dissolves the problems with PKI rather than
> trying to solve them, is trust-management systems (Blaze et al. 1999a,
Blaze
> et al. 1999b). These can be viewed as generalisations of longstanding
access
> control techniques for achieving security of software processes and data.
>
> Trust management systems are argued by Blaze (1999) to have five basic
> components:
>
> a language for describing `actions', which are operations with security
> consequences that are to be controlled by the system;
> a mechanism for identifying `principals', which are entities that can be
> authorised to perform actions;
> a language for specifying application `policies', which govern the actions
> that principals are authorised to perform;
> a language for specifying `credentials', which allow principals to
delegate
> authorisation to other principals; and
> a `compliance checker', which provides a service to applications for
> determining how an action requested by principals should be handled, given
a
> policy and a set of credentials.
> The trust management approach also offers ways of addressing privacy,
> because it is much less concerned about identified individuals, because it
> focusses primarily on privileges and restrictions; and because it can deal
> with nyms representing pseudonymous roles just as readily as with names
that
> are associated with an identified human.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> 9. Conclusions
> The originally perceived need was that, for e-commerce to become
mainstream,
> at least merchants, and probably also consumers, needed to identify
> themselves, and enable authentication of the identifiers they provided.
>
> But the technical orientation that has been adopted by the proponents of
PKI
> does not address the needs of the Information Society. The real social
need
> is for trust in e-interactions: for consumers to have security and
> convenience, but without surrendering personal data to sellers (and hence
to
> others who may gain access to it, such as other merchants, and agencies of
> government).
>
> Conventional X.509v3-based PKI suffers from such serious inadequacies that
> its application is highly suspect. The existence of an increasingly rich
set
> of alternatives to conventional, hierarchical PKI shows that the time has
> now come to recognise the inherent deficiencies of X.509 architectures,
> abandon attempts to impose them on open, public systems, and restrict
their
> use to within organisations that have strict hierarchical structures.
>
>
> --------------------------------------------------------------------------
--
> ----
>
> References
> Adams C. & Lloyd S. (1999) 'Understanding the Public-Key Infrastructure'
New
> Riders Publishing, 1999
>
> Austin T., Huaman D. & Austin T.W. (2000) 'Public Key Infrastructure
> Essentials', John Wiley & Sons, 2000
>
> Bacard A. (1995) 'The Computer Privacy Handbook: A Practical Guide to
E-Mail
> Encryption, Data Protection, and PGP Privacy Software', Peachpit Press
1995,
> at http://www.andrebacard.com/press.html
>
> Blaze M. (1999) 'Using the KeyNote Trust Management System', November
1999,
> at http://www.crypto.com/trustmgt/kn.html
>
> Blaze M., J. Feigenbaum J., Ioannidis J. & Keromytis A. (1999a) 'The
KeyNote
> Trust-Management System Version 2' RFC2704, IETF, September 1999, at
> http://www.crypto.com/papers/rfc2704.txt
>
> Blaze M., Feigenbaum J., Ioannidis J. & Keromytis A. (1999b) 'The Role of
> Trust Management in Distributed System Security' Chapter in Vitek & Jensen
> (Eds.) 'Secure Internet Programming: Security Issues for Mobile and
> Distributed Objects, Springer-Verlag, 1999, at
> http://www.crypto.com/papers/trustmgt.pdf
>
> Branchaud, M. (1997) 'A Survey of Public Key Infrastructures', Master's
> Thesis, Department of Computer Science, McGill University, Montreal, March
> 1997, at http://www.xcert.com/~marcnarc/PKI/thesis/
>
> Brands S.A. (2000) 'Rethinking Public Key Infrastructures and Digital
> Certificates: Building in Privacy' MIT Press, 2000
>
> Clarke R. (1993) 'Computer Matching and Digital Identity' Proc. Computers,
> Freedom & Privacy, February 1993, at
> http://www.anu.edu.au/people/Roger.Clarke/DV/CFP93.html
>
> Clarke R. (1994a) 'The Digital Persona and its Application to Data
> Surveillance' The Information Society 10,2 (June 1994), at
> http://www.anu.edu.au/people/Roger.Clarke/DV/DigPersona.html
>
> Clarke R. (1994b) 'Information Technology: Weapon of Authoritarianism or
> Tool of Democracy?' Proc. World Congress, Int'l Fed. of Info. Processing,
> Hamburg, September 1994. At
> http://www.anu.edu.au/people/Roger.Clarke/DV/PaperAuthism.html
>
> Clarke R. (1994c) 'Human Identification in Information Systems: Management
> Challenges and Public Policy Issues' Info. Technology & People 7,4
(December
> 1994). At http://www.anu.edu.au/people/Roger.Clarke/DV/HumanID.html
>
> Clarke R. (1996) 'Cryptography in Plain Text', Privacy Law & Policy
Reporter
> 3, 2 (May 1996) 24-27, 30-33, at
> http://www.anu.edu.au/people/Roger.Clarke/II/CryptoSecy.html
>
> Clarke R. (1997) 'Chip-Based ID: Promise and Peril' Proc. Int'l Conf. on
> Privacy, Montreal, 23-26 September 1997, at
> http://www.anu.edu.au/people/Roger.Clarke/DV/IDCards97.html
>
> Clarke R. (1998) 'Public Key Infrastructure: Position Statement', May
1998,
> at http://www.anu.edu.au/people/Roger.Clarke/DV/PKIPosn.html
>
> Clarke R. (1999a) 'Privacy-Enhancing and Privacy-Sympathetic Technologies:
> Resources', April 1999, at
> http://www.anu.edu.au/people/Roger.Clarke/DV/PEPST.html
>
> Clarke R. (1999b) 'Identified, Anonymous and Pseudonymous Transactions:
The
> Spectrum of Choice' Proc. User Identification & Privacy Protection Conf.,
> Stockholm, 14-15 June 1999, at
> http://www.anu.edu.au/people/Roger.Clarke/DV/UIPP99.html
>
> Clarke R. (1999c) 'The Willingness of Net-Consumers to Pay: A
> Lack-of-Progress Report', Proc. 12th International Bled EC Conf.,
Slovenia,
> June 1999, at http://www.anu.edu.au/people/Roger.Clarke/EC/WillPay.html
>
> Clarke R. (2000a) 'Privacy Requirements of Public Key Infrastructure'
> Internet Law Bulletin 3, 1 (April 2000) 2-6. Republished in 'Global
> Electronic Commerce', published by the World Markets Research Centre in
> collaboration with the UN/ECE's e-Commerce Forum on 'Electronic Commerce
for
> Transition Economies in the Digital Age', 19-20 June 2000, at
> http://www.anu.edu.au/people/Roger.Clarke/DV/PKI2000.html
>
> Clarke R. (2000b) 'Interview', September 2000, at
> http://www.anu.edu.au/people/Roger.Clarke/DV/BiometixIview.html
>
> Diffie W. & Hellman M. (1976) 'New directions in cryptography' IEEE
> Transactions on Information Theory, pp. 644-654, November 1976
>
> Ellison C. (1996) 'Establishing Identity Without Certification
Authorities',
> Proc. 6th USENIX Security Symposium, San Jose CA, July 22-25, 1996, at
> http://world.std.com/~cme/usenix.html
>
> Ellison C. (1997) 'What do you need to know about the person with whom you
> are doing business?' Written testimony of Carl M. Ellison to the U.S.
House
> of Representatives Science and Technology Subcommittee, Hearing of 28
> October 1997: Signatures in a Digital Age, at
> http://world.std.com/~cme/html/congress1.html
>
> Ellison C. (1999) 'The nature of a usable PKI' Computer Networks 31 (1999)
> 823-830
>
> Ellison C. (2000) 'Naming and Certificates', Proc. Computers, Freedom &
> Privacy 2000, at http://www.cfp2000.org/papers/ellison.pdf
>
> Ellison C. (2000) 'SPKI/SDSI and the Web of Trust' September 2000, at
> http://world.std.com/~cme/html/web.html
>
> Ellison C. & Schneier B. (2000a) 'Risks of PKI: Electronic Commerce'
Inside
> Risks 116, Commun. ACM 43, 2 (February 2000), at
> http://www.counterpane.com/insiderisks5.html
>
> Ellison C. & Schneier B. (2000b) 'Ten Risks of PKI: What You're Not Being
> Told About Public Key Infrastructure' Computer Security Journal, v 16, n
1,
> 2000, pp. 1-7, at http://www.counterpane.com/pki-risks.html
>
> EPIC (1997-) 'EPIC Online Guide to Practical Privacy Tools', at
> http://www.epic.org/privacy/tools.html
>
> Ford W. & Baum M.S. (1997) 'Secure Electronic Commerce: Building the
> Infrastructure for Digital Signatures and Encryption', Prentice Hall, 1997
>
> Froomkin A.M. (1996) 'The Essential Role of Trusted Third Parties in
> Electronic Commerce' Oregon L. Rev. 75,1 (Spring, 1996) 49-115
>
> Garfinkel S. (1995) 'PGP: Pretty Good Privacy' O'Reilly & Associates,
1995,
> AT http://www.ora.com/catalog/pgp/
>
> Greenleaf G.W. & Clarke R. (1997) `Privacy Implications of Digital
> Signatures', IBC Conference on Digital Signatures, Sydney (March 1997), at
> http://www.anu.edu.au/people/Roger.Clarke/DV/DigSig.html
>
> Grossman W. (2000) 'Circles of Trust', Scientific American, August 2000,
at
> http://www.sciam.com/2000/0800issue/0800cyber.html
>
> Housley R., Ford W., Polk W. and Solo D. (1999) 'Internet X.509 Public Key
> Infrastructure Certificate and CRL Profile', RFC 2459, January 1999, at
> http://www.ietf.org/rfc/rfc2459.txt
>
> IETF (1997-) 'Simple Public Key Infrastructure (SPKI)', at
> http://www.ietf.org/html.charters/spki-charter.html
>
> Kaiser T. (2000) 'Secure Storage of Private Keys on Commodity
Workstations',
> Unpublished Honours Thesis, Department of Computer Science, Australian
> National University, November 2000
>
> Khare R. & Rifkin A. (1997) 'Weaving a Web of Trust' Revised version of a
> paper World Wide Web Journal 2 3 (Summer 1997) 77-112, at
> http://www.cs.caltech.edu/~adam/local/trust.html
>
> Lampson B., Abadi M., Burrows M. & Wobber E. (1992) 'Authentication in
> distributed systems: theory and practice' ACM Transactions on Computer
> Systems, 10(4):265{310, November 1992, at
>
http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-083.
> html
>
> McCullagh D. (1996-) 'Nym', at http://www.well.com/user/declan/nym/
>
> McCullagh A. & Caelli W. (2000) 'Non-Repudiation in the Digital
Environment'
> First Monday 5, 8 (August 2000), at
> http://firstmonday.org/issues/issue5_8/mccullagh/index.html
>
> Maurer U. (1996) 'Modelling a Public-Key Infrastructure' Proc. 1996
European
> Symposium on Research in Computer Security (ESORICS' 96), Lecture Notes in
> Computer Science, Springer-Verlag, vol. 1146, pp. 325-350, 1996, at
> ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/wwwisc/Maurer96b.pdf
>
> Rivest R.L. & Lampson B. (1996) 'SDSI - A Simple Distributed Security
> Infrastructure', 15 Sep 1996, at
> http://theory.lcs.mit.edu/~rivest/sdsi10.html
>
> Schneier B. (1996) 'Applied Cryptography' Wiley, 2nd Ed., 1996
>
> SDSI (1996-) 'A Simple Distributed Security Infrastructure (SDSI)', 1996-,
> at http://theory.lcs.mit.edu/~cis/sdsi.html
>
> Stallings W. (1995) 'Protect Your Privacy: The PGP User's Guide' Prentice
> Hall, 1995
>
> W3C (2000) 'Public-Key Infrastructure (X.509) (pkix)', at
> http://www.ietf.org/html.charters/pkix-charter.html
>
> Wang Y. (1998) 'SPKI' December 1998, at
> http://www.hut.fi/~yuwang/publications/SPKI/SPKI.html
>
> X.509 (1988) 'The Directory - Authentication Framework', Volume VIII of
> CCITT Blue Book, pages 48-81, CCITT, 1988
>
> Zimmermann P.R. (1995) 'PGP 5.0 User's Guide' MIT Press, 1995, at
> http://mitpress.mit.edu/book-home.tcl?isbn=0262740176
>
>
> --------------------------------------------------------------------------
--
> ----
>
> Navigation
> Go to Roger's Home Page.
>
> Go to the contents-page for this segment.
>
> Send an email to Roger
>
> Created: 6 November 2000
>
> Last Amended: 9 November 2000
>
>
> --------------------------------------------------------------------------
--
> ----
> These community service pages are a joint offering of the Australian
> National University (which provides the infrastructure), and Roger Clarke
> (who provides the content).
> The Australian National University
> Visiting Fellow, Faculty of
> Engineering and Information Technology,
> Information Sciences Building Room 211 Xamax Consultancy Pty Ltd, ACN: 002
> 360 456
> 78 Sidaway St
> Chapman ACT 2611 AUSTRALIA
> Tel: +61 2 6288 1472, 6288 6916
>
> To unsubscribe send the following in the body of a message to
> listserv@abanet.org - unsubscribe st-isc
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19978 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 12:40:36 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id PAA17454 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 15:25:04 -0500 (EST)
Message-Id: <200011132025.PAA17449@roadblock.missi.ncsc.mil>
Date: Mon, 13 Nov 2000 15:40:19 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: OCSP-X vs SCVP
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: BDJuVGQ7uvrFshW7ghd4WA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
> From: "Anders Rundgren" <anders.rundgren@telia.com>
>
> Actually I don't sugggest that an 'equivalent' XML implementation is to be
> created. A brand new scheme is what I believe is needed.
>
> One reason for wanting ACs to use XMLDSIG is to be able to specify the specifc
> local/global/national/application/whatever attribute profile as an XML schema.
> Because unlike PKCs the variation in ACs is virtually unlimited which makes
this "feature" extremely critical.
> And also unlike PKCs the exact interpretation of virtually all fields is
probably a requirement in just about
> all likely applications. <<<< I.e. an AC is really a "message" to be acted
upon >>>>
I'm sorry, I don't follow the above. In a PKC, an "exact
interpretation" of all fields is a requirement - Validity is not just
two strings, it is two dates which must be compared against a system
clock to determine if the cert is within range. Subject and Issuer are
not only displayed, they are chained, and used as search criteria.
Public key is not just a string of bits, it is a cryptographic value
which is used in a defined algorithm in a defined manner. The syntax
(the order of fields, the field types, and value constraints) are not
sufficient to act upon a PKC; the application must know what each field
means and process it accordingly.
In contrast, I don't see how an XML schema, whether it is local/global/
application/whatever, can communicate anything more about the semantics
of a message (how it is to be acted upon) than can an ASN.1 type
definition. Java can say "convert this digit string to a timeval
and compare it to the system clock", but how can you say such a thing
using XML? W3C claims: "The XML Schema Working Group is addressing means
for defining the structure, content, and semantics of XML documents", but
here "semantics" is in the eye of the writer. I believe you can use
XML to label data values for "customer record" and "shoe size", but I
don't believe that an XML DTD can express the fact that the "key usage"
field of a certificate is involved in determining the validity of a
cert path (i.e. that a path is a series of zero or more CA certificates
followed by a single End Entity certificate). The XML notion of
"semantics" might more accurately be called "data labels". I'd be
surprised to learn of some semantic capability that can be expressed in
an XML DTD but not in ASN.1.
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15177 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 11:11:11 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G3Z00M019MQ6G@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 13 Nov 2000 11:18:26 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G3Z00LLG9MQAR@ext-mail.valicert.com>; Mon, 13 Nov 2000 11:18:26 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NLKPV>; Mon, 13 Nov 2000 11:16:28 -0800
Content-return: allowed
Date: Mon, 13 Nov 2000 11:16:27 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: Should PKIX protocols support XML well
To: "'Stephen Kent'" <kent@bbn.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E152FB9@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Hi Steve/Russ,
I hope nothing that I posted even implied that I recommend that
certs and CRLs be encoded in XML. I think there is enough investment
in ASN.1 certs/CRLs etc. to not make it a worthwhile effort. The
remark I was trying to make is that I think future PKIX work should
try and see if specifying protocols in XML or both XML and ASN.1
make sense for the task they are trying to do.
This is precisely why I tried to specify SCVP in both syntaxes.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Monday, November 13, 2000 11:04 AM
> To: Ambarish Malpani
> Cc: 'ietf-pkix@imc.org '
> Subject: Re: Should PKIX protocols support XML well
>
>
> Ambarish,
>
> XML has various benefits for representing certain kinds of data, but
> none of those seem especially relevant to the encoding of certs or
> CRLs. Moreover, at a time when people in various quarters (e.g.,
> wireless folks) complain about the size of certs, it would not seem
> especially appropriate to adopt an XML encoding, which would increase
> the size of these data items.
>
> I am not persuaded by comments that allude only to the "trendiness"
> of XML vs. ASN.1 encoding, as several others have pointed out. PKIX
> was started as a profiler of X.509 protocols, and we have expanded
> our charter to create new protocols that support X.509 certs and
> which seem appropriate to PKI use in the Internet. That makes it hard
> to justify developing new syntax for existing data structures, as
> noted above. However, as Russ pointed out, standards for carriage of
> certs and CRLs (ASN.1 encoded) in an XML context are not out of the
> question.
>
> Steve
>
----------------Russ's Original Message-------------
Ambarish:
I agree that we need to support XML clients. It would not have been one of
my three criteria if I thought otherwise. However, I do not think that we
should abandon ASN.1. I think that certificates and CRLs MUST be ASN.1
encoded. Providing an XML wrapper to carry an ASN.1-encoded blob is just
fine. Base64-encode it if you like. Anyway, the server can obtain the
ASN.1-encode certificate perform validation services. The server will
return an indication of validity and parse some information (especially the
public key, alt names, and critical extension information) from the
certificate. This will allow the client to be completely ASN.1 ignorant.
I realize that this is just one aspect of making the entire system XML
client friendly; however, I think that it is a very reasonable place to
begin. In many systems, enrollment is handled by issuing a token (such as
a smart card). In this case, the client has nothing to do with
enrollment. So, certificate validation is a good place to begin.
Russ
-------------End of Message----------------------------
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14339 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 11:05:07 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11986; Mon, 13 Nov 2000 14:12:22 -0500 (EST)
Message-Id: <200011131912.OAA11986@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>, IANA <iana@iana.org>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ietf-pkix@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols to Experimemntal
Date: Mon, 13 Nov 2000 14:12:22 -0500
Sender: scoya@cnri.reston.va.us
The IESG has approved the Internet-Draft 'Internet X.509 Public Key
Infrastructure Data Validation and Certification Server Protocols'
<draft-ietf-pkix-dcs-07.txt> as an Experimental Protocol. This
document is the product of the Public-Key Infrastructure (X.509)
Working Group. The IESG contact persons are Jeffrey Schiller and
Marcus Leech.
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14223 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 11:03:54 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA11949; Mon, 13 Nov 2000 14:11:13 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v04220805b635ea7c6b39@[171.78.30.107]>
In-Reply-To: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com>
Date: Mon, 13 Nov 2000 14:04:29 -0500
To: Ambarish Malpani <ambarish@valicert.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Should PKIX protocols support XML well
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Ambarish,
XML has various benefits for representing certain kinds of data, but
none of those seem especially relevant to the encoding of certs or
CRLs. Moreover, at a time when people in various quarters (e.g.,
wireless folks) complain about the size of certs, it would not seem
especially appropriate to adopt an XML encoding, which would increase
the size of these data items.
I am not persuaded by comments that allude only to the "trendiness"
of XML vs. ASN.1 encoding, as several others have pointed out. PKIX
was started as a profiler of X.509 protocols, and we have expanded
our charter to create new protocols that support X.509 certs and
which seem appropriate to PKI use in the Internet. That makes it hard
to justify developing new syntax for existing data structures, as
noted above. However, as Russ pointed out, standards for carriage of
certs and CRLs (ASN.1 encoded) in an XML context are not out of the
question.
Steve
Received: from jlc.net (3ff83a80.dsl.flashcom.net [63.248.58.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12967 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 10:31:56 -0800 (PST)
Received: (from pkoning@localhost) by jlc.net (8.9.3/8.8.7) id NAA01544; Mon, 13 Nov 2000 13:39:16 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14864.13652.365042.449654@pkoning.ironstream.com>
Date: Mon, 13 Nov 2000 13:39:16 -0500 (EST)
From: Paul Koning <pkoning@ironstream.com>
To: timothyf@mindspring.com
Cc: ambarish@valicert.com, ietf-pkix@imc.org
Subject: Re: Should PKIX protocols support XML well
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com> <771031101775.20001111172812@mindspring.com>
X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid
>>>>> "Timothy" == Timothy Fisher <timothyf@mindspring.com> writes:
Timothy> Ambarish,
Timothy> I support your comments and think they they are well put...
Timothy> Outside of the IETF, I know from personal experience that
Timothy> there is a growing opinion that the PKI standards based on
Timothy> ASN1 are "behind the times." Those of you who don't agree
Timothy> with that statement, please don't argue the point to me, I
Timothy> am simply conveying what I feel is a growing opinion.
Timothy> The IETF would be wise to consider XML in future PKI work...
If the basis of that desire is religious bias, which is what phrases
like "behind the times" suggests, then I see no merit in this.
On the other hand, if there are technical benefits, that's different.
Certainly I'm no fan of BER (don't know DER as well). But if the best
argument against this set of standards is that they are old fashioned,
that's not an argument with merit. Growing opinion or not -- that
doesn't matter.
paul
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06141 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 08:36:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22919; Mon, 13 Nov 2000 11:43:31 -0500 (EST)
Message-Id: <200011131643.LAA22919@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ietf-pkix@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure Qualified Certificates Profile to Proposed Standard
Date: Mon, 13 Nov 2000 11:43:31 -0500
Sender: scoya@cnri.reston.va.us
The IESG has approved the Internet-Draft 'Internet X.509 Public Key
Infrastructure Qualified Certificates Profile'
<draft-ietf-pkix-qc-06.txt> as a Proposed Standard. This document is
the product of the Public-Key Infrastructure (X.509) Working Group.
The IESG contact persons are Jeffrey Schiller and Marcus Leech.
Technical Summary
This document defines a profile of RFC2459 (PKIX Part I) certificates
that have specific attributes.
The term "Qualified Certificate" has been used by the European
Commission to describe a certain type of certificates with specific
relevance for European legislation. This specification is intended to
support this class of certificates, but its scope is not limited to
this application.
Within this standard the term "Qualified Certificate" is used more
generally, describing the format for a certificate whose primary
purpose is identifying a person with high level of assurance in public
non-repudiation services.
Working Group Summary
The Working Group has come to consensus on this specification.
Protocol Quality
Jeffrey I. Schiller reviewed this document for the IESG.
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06037 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 08:35:56 -0800 (PST)
Received: from mega (t6o69p105.telia.com [213.64.110.225]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id RAA15541; Mon, 13 Nov 2000 17:43:10 +0100 (CET)
Message-ID: <003201c04d90$9dc90440$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>, <ietf-pkix@imc.org>
References: <200011131449.JAA13360@roadblock.missi.ncsc.mil>
Subject: Re: OCSP-X vs SCVP
Date: Mon, 13 Nov 2000 17:41:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA06040
David,
<snip>
> The idea of a standard XML schema is that each protocol would *not*
> need to specify how to translate one to the other. Every protocol
> would use the same translation.
>
> The protocol document ensures that the ASN.1 and the XML specifications
> are equivalent (by mechanically generating one from the other), and
> once that is done, the VB programmer doesn't have to know jack about
> ASN.1 in order to write an application which exchanges data to and from
> an ASN.1 application operating in text mode!
I may be off-track but I don't see how you can generate an XML shema from an ASN.1 spec
without having an "ASN.1-shema". Or was the idea that the protocol document is
an XML schema only? On-the-wire format, would it be XML *or* DER?
I see no point in doing that.
> Anders seems puzzled that his suggestion to discard ACs and replace
> them with something written in XML was not warmly received, but that
> specifying SCVP etc in both ASN.1 and XML seems to be getting more
> support. This is not puzzling; the former involves inventing something
> 'equivalent' from scratch, whereas the latter involves first
> standardizing the information to be exchanged and then writing two
> equivalent ways of encoding that information.
Actually I don't sugggest that an 'equivalent' XML implementation is to be
created. A brand new scheme is what I believe is needed.
One reason for wanting ACs to use XMLDSIG is to be able to specify the specifc
local/global/national/application/whatever attribute profile as an XML schema.
Because unlike PKCs the variation in ACs is virtually unlimited which makes this "feature" extremely critical.
And also unlike PKCs the exact interpretation of virtually all fields is probably a requirement in just about
all likely applications. <<<< I.e. an AC is really a "message" to be acted upon >>>>
OK, you *can* represent the entire AC attribute part as *one* XML schema but that
is IMO to use XML the wrong way as it leaves practically all interpretation (guesswork) to
the application layer. Using a *specific* named schema for each profile things gets much easier.
Another reason to use a "self-contained signed attribute container object" instead of
defining a "certificate" is that you eliminate the need for direct protocol support of things like
cert-path information which could be critical given the "lukewarm" interest to change TLS etc.
And certificates stay in current PKC form (XML or ASN.1).
Using XMLDSIG, ACs would be "yet another business message profile" riding on top
of what others are aleady building, instead of a separate infrastructure.
How do you anticipate that ASN.1 ACs should be differentiated and read (identified, parsed, and
checked for correctness vs a specific profile definition) by verifier software?
With XML schemas, this is already in place without any plumbing at all.
Either the verifier application recognizes the specific AC profile as indicated by the schema
or not. I see no such possibility with ASN.1 without requiring constant updates of
the reader/parser part.
I.e. to *me* the XML-schema-route is a one-way street with no easy (automatic) turning back.
Regards
Anders
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27036 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 07:04:49 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA13366 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 09:49:17 -0500 (EST)
Message-Id: <200011131449.JAA13360@roadblock.missi.ncsc.mil>
Date: Mon, 13 Nov 2000 10:04:30 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: RE: OCSP-X vs SCVP
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: uol44unSc1mmrzIcJH7ipg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
> From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
>
> This will provide a means to extend the capability
> deployed today - the ability to unambiguously encode
> and decode a value of an ASN.1 type. A standard markup
> for the ASN.1 notation will provide a new format for
> expressing the same ASN.1 values.
>
> By binding a standard markup to the values defined as
> valid for ASN.1 types, it will be possible for an ASN.1
> application to send or receive ASN.1 values in either
> text or binary formats.
Phil,
This description does not do justice to the powerful advantages a
standard XML schema would provide. See below.
> From: Dan Ash <daniel.ash@identrus.com>
>
> I might be completely off track here, but is it possible, and does it
> make sense to include within the definition of a protocol not only
> different languages to represent the content, but also a specification
> of how to translate from one language to the another? If so, perhaps
> some arbitrary software (independent of the client or the server) could
> translate from one language to another... allowing both the client and
> the server to deploy in either language. This might alleviate the
> problems mentioned above.
Dan,
The idea of a standard XML schema is that each protocol would *not*
need to specify how to translate one to the other. Every protocol
would use the same translation.
The protocol document ensures that the ASN.1 and the XML specifications
are equivalent (by mechanically generating one from the other), and
once that is done, the VB programmer doesn't have to know jack about
ASN.1 in order to write an application which exchanges data to and from
an ASN.1 application operating in text mode!
Anders seems puzzled that his suggestion to discard ACs and replace
them with something written in XML was not warmly received, but that
specifying SCVP etc in both ASN.1 and XML seems to be getting more
support. This is not puzzling; the former involves inventing something
'equivalent' from scratch, whereas the latter involves first
standardizing the information to be exchanged and then writing two
equivalent ways of encoding that information. Applications can be
developed completely independently - XML developers use their favorite
tools to implement the XML protocol specification, ASN.1 developers use
their favorite tools to implement text mode encoding from the ASN.1
protocol specification, and the two applications work together.
I believe that PKIX should evolve to include both ASN.1 and XML
specifications of each protocol, and should require that those
specifications be equivalent for each protocol which includes
an XML specification.
> From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
>
> What I am proposing is to modify the ASN.1
> standards so that the values of all ASN.1 types can
> be expressed using a common XML markup.
I agree. But just as RFC 2459 includes both 88 and 92 appendices,
PKIX documents should include both ASN.1 and standalone XML appendices.
Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26508 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 06:59:13 -0800 (PST)
Received: from identrus.com (192.168.100.92 [192.168.100.92]) by blue.identrus.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WW3AWSL5; Mon, 13 Nov 2000 10:03:33 -0500
Sender: dash
Message-ID: <3A10037E.FAE79544@identrus.com>
Date: Mon, 13 Nov 2000 10:06:38 -0500
From: daniel ash <daniel.ash@identrus.com>
Reply-To: daniel.ash@identrus.com
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Peter H. Gien" <pgien@home.com>
CC: ietf-pkix@imc.org
Subject: Re: OCSP-X vs SCVP
References: <000001c04d00$25f0a300$e8c80318@etntwn1.nj.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Peter H. Gien" wrote:
> Dan,
>
> Forgive me if I digress from the original topic.
> Let's agree that ASN.1 and XML are not really languages such as C and Java.
> As such, ASN.1 and XML are simply tag formats that are used to describe
> data. I cannot compile ASN.1 nor can I execute XML. The use of one or the
> other would not necessarily result in "code bloat". Data bloat yes.
>
I didn't intend to imply 'programming language'... 'language' is clear enough
in context.
>
> One thing that is for sure though, is that any budding VB programmer can
> open an XML document without any trouble. MSXML.DLL is already on their
> machine and it opens the document as if by magic. A little more study,
> effort and insight is needed to open an ASN.1 file. (OK, a lot more...)
>
You could find, or easily develop something to decode and "open" an ASN.1
structure. I believe the argument stems from the fact that the syntax of XML
languages is easier to adopt for people who already have experience using
markup languages(which covers the large base of HTML programmers).... also that
the syntax is generally more intuitive.
>
> I'd like to add that going forward, XML should be a standard way of
> describing all PKIX data structures. Think what has happened to assembly
> programming? Delegated to the specialist backwaters of computing (Too much
> studying, effort and insight was required). It was replaced with C and
> shortly thereafter with C++. The same analogy applies to ASN.1 and XML. The
> standard that requires the least amount of intellectual effort to comprehend
> and implement is the one that wins. This does not always translate to the
> best standard!)
>
> So without sparking a riot, I'd like to agree with the rest of you who are
> advocating XML.
>
> Thanks
> Peter H. Gien
>
> -----Original Message-----
> From: dash@ns.secondary.com [mailto:dash@ns.secondary.com]On Behalf Of
> Dan Ash
> Sent: Sunday, November 12, 2000 6:36 PM
> To: ietf-pkix@imc.org
> Subject: RE: OCSP-X vs SCVP
>
> The SCVP draft defines syntax for both ASN.1 and XML A question about
> this arose on the list a few months back, where it was mentioned that
> supporting both languages would:
> - cause "code bloat".
> - significantly increase the testing burden
> - and cause potential discrepancy when translating from one
> language to another.
>
> I might be completely off track here, but is it possible, and does it
> make sense to include within the definition of a protocol not only
> different languages to represent the content, but also a specification
> of how to translate from one language to the another? If so, perhaps
> some arbitrary software (independent of the client or the server) could
> translate from one language to another... allowing both the client and
> the server to deploy in either language. This might alleviate the
> problems mentioned above.
>
> In any case, this issue of ASN.1 vs XML is obviously a complex one.
> ASN.1 is ingrained in all of PKIX's work... while the user community is
> demanding XML.. and for PKIX to begin incorporating XML in anything, I
> think there needs to be a direction and a consistent strategy to move
> forward with. If there isn't any general direction and strategy, then
> I believe that we'd only be promoting confusion. For this, I certainly
> agree with Ambarish....that the XML vs. ASN.1 topic should be discussed
> independently of OCSPv2 and SCVP so that it may be more clear of how we
> can and should proceed if and when it is decided to integrate XML
> representation into PKIX efforts.
>
> ... Also, I do agree that the topic should be awarded priority if it
> hasn't already.
>
> -dan
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21505 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 05:54:38 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA13673; Mon, 13 Nov 2000 06:01:17 -0800 (PST)
Message-Id: <4.3.2.7.2.20001110162319.01a456d0@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 10 Nov 2000 16:42:52 -0500
To: Ambarish Malpani <ambarish@valicert.com>
From: Russ Housley <housley@spyrus.com>
Subject: Re: Should PKIX protocols support XML well
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
In-Reply-To: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Ambarish:
I agree that we need to support XML clients. It would not have been one of
my three criteria if I thought otherwise. However, I do not think that we
should abandon ASN.1. I think that certificates and CRLs MUST be ASN.1
encoded. Providing an XML wrapper to carry an ASN.1-encoded blob is just
fine. Base64-encode it if you like. Anyway, the server can obtain the
ASN.1-encode certificate perform validation services. The server will
return an indication of validity and parse some information (especially the
public key, alt names, and critical extension information) from the
certificate. This will allow the client to be completely ASN.1 ignorant.
I realize that this is just one aspect of making the entire system XML
client friendly; however, I think that it is a very reasonable place to
begin. In many systems, enrollment is handled by issuing a token (such as
a smart card). In this case, the client has nothing to do with
enrollment. So, certificate validation is a good place to begin.
Russ
At 11:08 AM 11/10/2000 -0800, Ambarish Malpani wrote:
>There are a bunch of industries/communities that are using XML
>throughout their systems - all their messages are in XML, all
>their development is in XML and XML is their chosen future
>direction.
>
>We may or may not agree about whether this is a wise decision, but
>that decision has been made and is one that we (PKIX) can not
>change.
>
>Now the question is, do we try and support such groups in their
>efforts or do we say: "Sorry, we think you did the wrong thing
>by not picking ASN.1, so go figure out how to do public key
>cryptography by yourself - we won't help"
>
>My personal bias is that if a significant percent of the world
>is headed towards XML, it makes more sense for us to support that
>group and make sure that when they do PKI, they do it in a
>secure way, rather than ignore that world and have them do PKI
>either insecurely, or in n different ways. After having seen
>different standards groups, I am quite convinced that IETF
>actually do a pretty good job with their specifications and the
>thoroughness with which specifications are reviewed. I think it
>is our responsibility to help set the standards so that people
>can use them in most significant environments, rather than have us
>ignore the issue and have people not only do it in less secure
>ways, but also have different groups do the same job in
>different ways.
>
>[Note: I am not trying to say that IETF should set all standards
>in the world, but it does need to acknowledge and react to the
>needs of large and diverse groups. And the XML community is one
>such group].
>
>Comments?
>Ambarish
>
>
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect 650.567.5457
>ValiCert, Inc. ambarish@valicert.com
>339 N. Bernardo Ave. http://www.valicert.com
>Mountain View, CA 94043
>
>
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA18649 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 05:08:33 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA25690; Mon, 13 Nov 2000 14:21:45 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA21586; Mon, 13 Nov 2000 14:15:15 +0100
Message-ID: <3A0FE965.B6C09500@bull.net>
Date: Mon, 13 Nov 2000 14:15:17 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Sean Mullan <sean.mullan@sun.com>
CC: ietf-pkix@imc.org
Subject: Re: JSR-000055 Certification Path API
References: <3A0FD6AD.611581A6@sun.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA18650
Sean,
Thanks for the information. Would it be possible to get a printable version
of the whole document, e.g. *.pdf (or *.doc) which includes a fixed number
of pages so that it becomes easier to point to the text to raise comments ?
Denis
> All,
>
> The Java Certification Path API is now available for Public
> Review. This is a new Java API that is being specified using
> the Java Community Process (see
> http://java.sun.com/aboutJava/communityprocess for more info
> on the process).
>
> This API is being targeted for inclusion in the next release (1.4)
> of J2SE (Java 2 Platform, Standard Edition). The API includes interfaces
> and classes for building and validating chains of certificates.
>
> The API is based on the existing Java Cryptography Architecture
> (see http://java.sun.com/j2se/1.3/docs/guide/security/CryptoSpec.html)
> which allows developers to create and plug in cryptographic service
> providers supporting various algorithms. The API also includes
> a set of algorithm-specific classes supporting the PKIX certification
> path validation algorithm.
>
> The public review period closes on December 8. See the forwarded message
> below for details on downloading the specification. Please send any
> comments you may have to the email address "certpath-experts-lead@ireland.sun.com".
> We expect that many of you will be interested in this API and we look
> forward to your comments.
>
> Thanks,
> Sean Mullan
> Specification Lead for JSR055
> Java Security and Networking
> Sun Microsystems
>
> ----------------------------------------------------------------------------
>
> Objet: JSR-000055 Certification Path API
> Date: Thu, 9 Nov 2000 15:06:26 -0800
> De: Harold Ogle <Harold.Ogle@eng.sun.com>
> Répondre-A: "Java Community Process (JCP) general information/announcement
> list" <JCP-INTEREST@JAVA.SUN.COM>
> A: JCP-INTEREST@JAVA.SUN.COM
>
> The Public Review Draft Specification for
>
> JSR-000055 Certification Path API
>
> is now available for Public Review from
>
> http://java.sun.com/jcp/review.html
>
> This public review closes on December 8, 2000.
>
> The Maintenance Review of the JSPA, JSR 909, will end on December 5.
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JCP-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA17630 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 04:48:47 -0800 (PST)
Received: from plipp [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A4D21E10360; Mon, 13 Nov 2000 13:55:46 +0100
From: "Peter Lipp" <Peter.Lipp@iaik.at>
To: "Ambarish Malpani" <ambarish@valicert.com>, <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well
Date: Mon, 13 Nov 2000 13:55:57 +0100
Message-ID: <OEEELKIFKJHGADBKOFPNMEKDCAAA.Peter.Lipp@iaik.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com>
Importance: Normal
>My personal bias is that if a significant percent of the world
>is headed towards XML, it makes more sense for us to support that
>group and make sure that when they do PKI, they do it in a
>secure way, rather than ignore that world and have them do PKI
>either insecurely, or in n different ways.
I agree. And I fear if there is nothing on the horizon rather fast, we will
see several versions of things like e.g. XML-based certificates shortly. The
question is who will take the responsibility to head this? W3C having XML
under control? IETF having PKI-experience? A joint effort like with XMLDSig
seems optimal!
Peter
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11554 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 03:48:08 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA19859 for <ietf-pkix@imc.org>; Mon, 13 Nov 2000 03:55:26 -0800 (PST)
Received: from sun.com (boston [129.156.220.153]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id LAA11810; Mon, 13 Nov 2000 11:55:25 GMT
Sender: Sean.Mullan@ireland.sun.com
Message-ID: <3A0FD6AD.611581A6@sun.com>
Date: Mon, 13 Nov 2000 11:55:25 +0000
From: Sean Mullan <sean.mullan@sun.com>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: JSR-000055 Certification Path API
Content-Type: multipart/mixed; boundary="------------5A118088BB5C8A363B5909F4"
This is a multi-part message in MIME format.
--------------5A118088BB5C8A363B5909F4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
All,
The Java Certification Path API is now available for Public
Review. This is a new Java API that is being specified using
the Java Community Process (see
http://java.sun.com/aboutJava/communityprocess for more info
on the process).
This API is being targeted for inclusion in the next release (1.4)
of J2SE (Java 2 Platform, Standard Edition). The API includes interfaces
and classes for building and validating chains of certificates.
The API is based on the existing Java Cryptography Architecture
(see http://java.sun.com/j2se/1.3/docs/guide/security/CryptoSpec.html)
which allows developers to create and plug in cryptographic service
providers supporting various algorithms. The API also includes
a set of algorithm-specific classes supporting the PKIX certification
path validation algorithm.
The public review period closes on December 8. See the forwarded message
below for details on downloading the specification. Please send any
comments you may have to the email address "certpath-experts-lead@ireland.sun.com".
We expect that many of you will be interested in this API and we look
forward to your comments.
Thanks,
Sean Mullan
Specification Lead for JSR055
Java Security and Networking
Sun Microsystems
--------------5A118088BB5C8A363B5909F4
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from sunire.Ireland.Sun.COM (sunire [129.156.220.30])
by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id XAA19119
for <mullan@ireserver.Ireland.Sun.COM>; Thu, 9 Nov 2000 23:17:07 GMT
Received: from sunmail1.Sun.COM (sunmail1.Corp.Sun.COM [129.145.1.2])
by sunire.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id XAA18428
for <sean.mullan@ireland.sun.com>; Thu, 9 Nov 2000 23:17:05 GMT
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA15672;
Thu, 9 Nov 2000 15:17:03 -0800 (PST)
Received: from mail.java.sun.com (mail.javasoft.com [204.160.241.28])
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25452;
Thu, 9 Nov 2000 15:17:00 -0800 (PST)
Received: from mail (mail.java.sun.com [204.160.241.28])
by mail.java.sun.com (8.10.0.Beta13+Sun/8.10.2) with ESMTP id eA9NEv515151;
Thu, 9 Nov 2000 15:14:57 -0800 (PST)
Received: from JAVA.SUN.COM by JAVA.SUN.COM (LISTSERV-TCP/IP release 1.8d) with
spool id 1781043 for JCP-INTEREST@JAVA.SUN.COM; Thu, 9 Nov 2000
15:14:55 -0800
Approved-By: Harold.Ogle@ENG.SUN.COM
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by
mail.java.sun.com (8.10.0.Beta13+Sun/8.10.2) with ESMTP id
eA9N9Z513023 for <jcp-interest@java.sun.com>; Thu, 9 Nov 2000
15:09:35 -0800 (PST)
Received: from sunmail2.Sun.COM ([129.150.166.10]) by mercury.Sun.COM
(8.9.3+Sun/8.9.3) with ESMTP id PAA20817 for
<jcp-interest@java.sun.com>; Thu, 9 Nov 2000 15:07:38 -0800 (PST)
Received: from shorter.eng.sun.com (shorter.Eng.Sun.COM [129.144.125.35]) by
sunmail2.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.9) with ESMTP id
PAA07531 for <jcp-interest@java.sun.com>; Thu, 9 Nov 2000 15:07:37
-0800 (PST)
Received: from trangadst (trangadst [129.144.124.110]) by shorter.eng.sun.com
(8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id PAA00733 for
<jcp-interest@java.sun.com>; Thu, 9 Nov 2000 15:07:36 -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: q/JHpYJe7klIu6Uh77F76A==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Message-ID: <200011092307.PAA00733@shorter.eng.sun.com>
Date: Thu, 9 Nov 2000 15:06:26 -0800
Reply-To: "Java Community Process (JCP) general information/announcement
list" <JCP-INTEREST@JAVA.SUN.COM>
From: Harold Ogle <Harold.Ogle@eng.sun.com>
Subject: JSR-000055 Certification Path API
To: JCP-INTEREST@JAVA.SUN.COM
The Public Review Draft Specification for
JSR-000055 Certification Path API
is now available for Public Review from
http://java.sun.com/jcp/review.html
This public review closes on December 8, 2000.
The Maintenance Review of the JSPA, JSR 909, will end on December 5.
===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JCP-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
--------------5A118088BB5C8A363B5909F4--
Received: from femail8.sdc1.sfba.home.com (femail8.sdc1.sfba.home.com [24.0.95.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23832 for <ietf-pkix@imc.org>; Sun, 12 Nov 2000 15:19:11 -0800 (PST)
Received: from amdk6300 ([24.3.200.232]) by femail8.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001112232628.UPIG2160.femail8.sdc1.sfba.home.com@amdk6300> for <ietf-pkix@imc.org>; Sun, 12 Nov 2000 15:26:28 -0800
From: "Peter H. Gien" <pgien@home.com>
To: <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Sun, 12 Nov 2000 18:27:38 -0500
Message-ID: <000001c04d00$25f0a300$e8c80318@etntwn1.nj.home.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2212 (4.71.2419.0)
Importance: Normal
In-Reply-To: <3A0F297A.98258233@identrus.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Dan,
Forgive me if I digress from the original topic.
Let's agree that ASN.1 and XML are not really languages such as C and Java.
As such, ASN.1 and XML are simply tag formats that are used to describe
data. I cannot compile ASN.1 nor can I execute XML. The use of one or the
other would not necessarily result in "code bloat". Data bloat yes.
One thing that is for sure though, is that any budding VB programmer can
open an XML document without any trouble. MSXML.DLL is already on their
machine and it opens the document as if by magic. A little more study,
effort and insight is needed to open an ASN.1 file. (OK, a lot more...)
I'd like to add that going forward, XML should be a standard way of
describing all PKIX data structures. Think what has happened to assembly
programming? Delegated to the specialist backwaters of computing (Too much
studying, effort and insight was required). It was replaced with C and
shortly thereafter with C++. The same analogy applies to ASN.1 and XML. The
standard that requires the least amount of intellectual effort to comprehend
and implement is the one that wins. This does not always translate to the
best standard!)
So without sparking a riot, I'd like to agree with the rest of you who are
advocating XML.
Thanks
Peter H. Gien
-----Original Message-----
From: dash@ns.secondary.com [mailto:dash@ns.secondary.com]On Behalf Of
Dan Ash
Sent: Sunday, November 12, 2000 6:36 PM
To: ietf-pkix@imc.org
Subject: RE: OCSP-X vs SCVP
The SCVP draft defines syntax for both ASN.1 and XML A question about
this arose on the list a few months back, where it was mentioned that
supporting both languages would:
- cause "code bloat".
- significantly increase the testing burden
- and cause potential discrepancy when translating from one
language to another.
I might be completely off track here, but is it possible, and does it
make sense to include within the definition of a protocol not only
different languages to represent the content, but also a specification
of how to translate from one language to the another? If so, perhaps
some arbitrary software (independent of the client or the server) could
translate from one language to another... allowing both the client and
the server to deploy in either language. This might alleviate the
problems mentioned above.
In any case, this issue of ASN.1 vs XML is obviously a complex one.
ASN.1 is ingrained in all of PKIX's work... while the user community is
demanding XML.. and for PKIX to begin incorporating XML in anything, I
think there needs to be a direction and a consistent strategy to move
forward with. If there isn't any general direction and strategy, then
I believe that we'd only be promoting confusion. For this, I certainly
agree with Ambarish....that the XML vs. ASN.1 topic should be discussed
independently of OCSPv2 and SCVP so that it may be more clear of how we
can and should proceed if and when it is decided to integrate XML
representation into PKIX efforts.
... Also, I do agree that the topic should be awarded priority if it
hasn't already.
-dan
Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22331 for <ietf-pkix@imc.org>; Sun, 12 Nov 2000 14:26:59 -0800 (PST)
Received: from identrus.com (216.213.93.58 [216.213.93.58]) by blue.identrus.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WW3AWSDB; Sun, 12 Nov 2000 17:31:28 -0500
Sender: dash
Message-ID: <3A0F297A.98258233@identrus.com>
Date: Sun, 12 Nov 2000 18:36:26 -0500
From: Dan Ash <daniel.ash@identrus.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: RE: OCSP-X vs SCVP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The SCVP draft defines syntax for both ASN.1 and XML A question about
this arose on the list a few months back, where it was mentioned that
supporting both languages would:
- cause "code bloat".
- significantly increase the testing burden
- and cause potential discrepancy when translating from one
language to another.
I might be completely off track here, but is it possible, and does it
make sense to include within the definition of a protocol not only
different languages to represent the content, but also a specification
of how to translate from one language to the another? If so, perhaps
some arbitrary software (independent of the client or the server) could
translate from one language to another... allowing both the client and
the server to deploy in either language. This might alleviate the
problems mentioned above.
In any case, this issue of ASN.1 vs XML is obviously a complex one.
ASN.1 is ingrained in all of PKIX's work... while the user community is
demanding XML.. and for PKIX to begin incorporating XML in anything, I
think there needs to be a direction and a consistent strategy to move
forward with. If there isn't any general direction and strategy, then
I believe that we'd only be promoting confusion. For this, I certainly
agree with Ambarish....that the XML vs. ASN.1 topic should be discussed
independently of OCSPv2 and SCVP so that it may be more clear of how we
can and should proceed if and when it is decided to integrate XML
representation into PKIX efforts.
... Also, I do agree that the topic should be awarded priority if it
hasn't already.
-dan
Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA09155; Sat, 11 Nov 2000 22:25:50 -0800 (PST)
Received: from dad (dhcp090-2-151-24.nt01-c4.cpe.charter-ne.com [24.151.2.90]) by avocet.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id WAA00967; Sat, 11 Nov 2000 22:32:59 -0800 (PST)
Reply-To: <torrent@acm.org>
From: "Juan Rodriguez-Torrent" <torrent@acm.org>
To: "Paul Hoffman / IMC" <phoffman@imc.org>
Cc: <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Sun, 12 Nov 2000 01:33:03 -0500
Message-ID: <NDBBJKCNGLOIIBOHCOLHEEHACEAA.torrent@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <p05010443b63106d22030@[165.227.249.17]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Paul, I have to agree with your comments. This thread reminds me of a
company that went out of business a few days ago. After 5 years and $17 mil
the developers were still arguing that they did not need customer input.
Those folks could not understand why the sales team was unable to sell a
single copy of the "great" products that satisfied every whim, want, crave
and fad the lead developer threw at them.
Do we want lead developer(s) and PKIX "lordships" create the specs in a
vacuum? I think not! But lots of folks that could provide positive
contributions are scared silly just with the thought of having to face the
wrath of one of those "lordships". Recently it seems too easy for some
people that are icons in the PKIX and IETF to shoo people (eg "If you are
interested in XML and if you think it is appropriate, please advocate XML
ACs on the XML-DSIG mailing list"). So ... how do we solve the conundrum? I
say let's keep our sights to the real measure of success: A broad customer
base that freely and willingly embraces and pays for products that are PKIX
compliant. I don't see this yet and if we are so darn good at writing and
implementing standards why are organizations like the PKI Forum being
formed?
For some of the "lordships" of this working group it will be hard to believe
but there is a world outside the standards bodies and that world is working
hard trying to solve some very real and pressing business problems. Non-PKIX
compliant solutions are delivered and paid for daily -by the way, it is too
easy to take the Godly attitude and spit "Yeah! But they are doomed!"-. Each
one of those delivered solutions creates more confusion and instability to a
market that by now should be mature and stable. I see day in and day out
situations that require a combination of both, XML and PKIX based solutions
and that's why I have a hard time following a conversation between seemingly
intelligent people who have already adopted extremely hard and definitive
positions before all the facts are on the table. As Aldous Huxley said
"Facts do not cease to exist because they are ignored."
Consequently, I beg everyone in the working group to open your mind and
consider all the pros and cons before leading PKIX to what could be a
phenomenal strategic mistake. I hope we are not working on an engine and
shooing folks working on the gas!
Juan Rodriguez-Torrent
-----Original Message-----
From: Paul Hoffman / IMC [mailto:phoffman@imc.org]
Sent: Thursday, November 09, 2000 9:03 PM
To: Michael Zolotarev; Marc Branchaud
Cc: 'ietf-pkix@imc.org '
Subject: RE: OCSP-X vs SCVP
At 12:06 PM +1100 11/10/00, Michael Zolotarev wrote:
> >
>> > > But that ain't how the world works, and
>> > > that ain't how
>> > > people want it to work.
>> >
>> > Proof, please. I want the proof.
>> >
>>
>> The fact that people seem to care about this is proof enough for me...
>
>MArk, this is really speculative thing to say... I don't buy it as an
>argument, sorry.
It is not speculative. There have been people on this mailing list
who have said that they want an XML-based solution. Telling them that
you don't buy their opinion as an argument will tend to cause them
not to contribute again, yes? At that point, the WG will reduce to
those of us who are loud and repetitive. That is not a good way to
produce good protocols.
>Dont think it is a real issue with hosts and desktops. Dont think there is
>an issue with mobile devices either. I am not saying it is a bloat, or it
is
>not. I just want some approx figures. Compare bare-minimum
>ASNParser+OCSP_APIs with OCSP_XML_APIs ( for fairness I assume that XML
>parser is present on the platform regardless, so it doesn't count).
This level of argument reduces to "the customer is usually wrong".
That works in some areas, not in others. Given two protocols that
could meet the same objectives, such arguments are likely to squelch
input from the very people we should be listening to.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA08118 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 21:35:45 -0800 (PST)
Received: from asn-1.com (user-2ivf26s.dialup.mindspring.com [165.247.136.220]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id AAA25385; Sun, 12 Nov 2000 00:42:52 -0500 (EST)
Message-ID: <3A0E2E98.42E8A86A@asn-1.com>
Date: Sun, 12 Nov 2000 00:46:00 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rsalz@CaveoSystems.com
CC: ietf-pkix@imc.org
Subject: Re: OCSP-X vs SCVP
References: <200011111409.JAA11463@os390.caveosystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
>
> Certainly ASN.1 is older and parts are more stable, but it's also growing
> (and has grown -- PKIX1Explicit88, e.g.). So is XMLSchema. For the
> purposes of comparison, let's just call them equivalent.
But they are not. And you misunderstand. The module
PKIX1Explicit88 is not itself ASN.1. It is one module
of one specification written using ASN.1. It is a
collection of definitions based on ASN.1 types. The
values of these types conform to both the structure
and rules for values defined by the ASN.1 standards.
>
> >If there were but one XML schema life would
> >be easy. But there are many XML schema, and
> >more seem to be popping up in various XML
> >communities.
>
> That makes no more sense than saying there should be but one ASN.1 module.
No. An ASN.1 module is not a schema.
But ASN.1 can provide a schema for markup values
that are associated with ASN.1 type definitions.
This association makes it possible for ASN.1
applications to transfer values to and from XML
applications in a standard way. So ASN.1 can be
used to define another set of rules, like BizTalk,
DT4-DTD or XML-schema, for what constitutes valid
typed values. Markup is just another way to
represent these values.
>
> I'm not advocating that the IETF, the Security Area or the PKIX WG "use"
> XML (for some definition of use). I am trying to show that the XML
> communities are working to define *everything* needed to describe and
> exchange data. It might not make sense to use it -- I personally
> see little point in rewriting X.509v3 datatypes in XML-Schema -- but
> we should be aware of what's going on for if/when we do decide to work
> in that space.
> /r$
Agreed. What I am proposing is to modify the ASN.1
standards so that the values of all ASN.1 types can
be expressed using a common XML markup.
So that for an arbitrary type definition, say
MyType ::= SEQUENCE {
label PrintableString,
value INTEGER
}
a value of that type can be decoded by a recipient (or
encoded and transferred by a sender) using the markup
<MyType>
<label>
</label>
<value>
</value>
</MyType>
And so that a valid value of that ASN.1 type, a value
which conforms to the rules defined in the ASN.1
standards, such as
userValue MyType ::= {
label "My shoe size is ",
value 10
}
can be encoded and transferred as either ASN.1
encoded binary data or as the markup value
<MyType>
<label>
My shoe size is
</label>
<value>
10
</value>
</MyType>
This will provide a means to extend the capability
deployed today - the ability to unambiguously encode
and decode a value of an ASN.1 type. A standard markup
for the ASN.1 notation will provide a new format for
expressing the same ASN.1 values.
By binding a standard markup to the values defined as
valid for ASN.1 types, it will be possible for an ASN.1
application to send or receive ASN.1 values in either
text or binary formats.
Phil
----
Phillip H. Griffin Griffin Consulting
http://asn-1.com Secure ASN.1 Design & Implementation
+1-919-832-7008 1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Received: from inet-smtp4.us.oracle.com (inet-smtp4.oracle.com [209.246.15.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24612 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 15:16:48 -0800 (PST)
Received: from usmail07.us.oracle.com (usmail07.us.oracle.com [130.35.52.223]) by inet-smtp4.us.oracle.com (8.9.3/8.9.3) with ESMTP id PAA06151; Sat, 11 Nov 2000 15:23:58 -0800 (PST)
Received: from dlsun87.us.oracle.com (www-skreddy.us.oracle.com [144.25.18.64]) by usmail07.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id PAA26860; Sat, 11 Nov 2000 15:19:09 -0800 (PST)
Date: Sat, 11 Nov 2000 15:23:53 -0800 (PST)
From: Surendra K Reddy <skreddy@us.oracle.com>
To: Timothy Fisher <timothyf@mindspring.com>
cc: Ambarish Malpani <ambarish@valicert.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well
In-Reply-To: <771031101775.20001111172812@mindspring.com>
Message-ID: <Pine.SO4.4.05.10011111517330.18532-100000@dlsun87.us.oracle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I do agree with both of you on this. Around 2 years back, I have
implemented PKIX operational protocols using XML(XSN.1 -- XML
Syntax Notation 1) encoding as a proof of concept and I also
submitted a draft to ietf called WebCAP. There was a push back from PKIX
working group supporting XML based PKIX protocols. Now XML being used in
every sort of application, It is critical to support the effort to
standardize PKIX/XML.
Surendra Reddy
(650) 506 5441
On Sat, 11 Nov 2000, Timothy Fisher wrote:
>
> Ambarish,
>
> I support your comments and think they they are well put...
>
> Outside of the IETF, I know from personal experience that there is
> a growing opinion that the PKI standards based on ASN1 are "behind the
> times." Those of you who don't agree with that statement, please
> don't argue the point to me, I am simply conveying what I feel is a
> growing opinion.
>
> The IETF would be wise to consider XML in future PKI work...
>
> --
> Sincerely,
> Timothy Fisher mailto:timothyf@mindspring.com
>
>
>
> Friday, November 10, 2000, 2:08:48 PM, you wrote:
>
>
>
> AM> There are a bunch of industries/communities that are using XML
> AM> throughout their systems - all their messages are in XML, all
> AM> their development is in XML and XML is their chosen future
> AM> direction.
>
> AM> We may or may not agree about whether this is a wise decision, but
> AM> that decision has been made and is one that we (PKIX) can not
> AM> change.
>
> AM> Now the question is, do we try and support such groups in their
> AM> efforts or do we say: "Sorry, we think you did the wrong thing
> AM> by not picking ASN.1, so go figure out how to do public key
> AM> cryptography by yourself - we won't help"
>
> AM> My personal bias is that if a significant percent of the world
> AM> is headed towards XML, it makes more sense for us to support that
> AM> group and make sure that when they do PKI, they do it in a
> AM> secure way, rather than ignore that world and have them do PKI
> AM> either insecurely, or in n different ways. After having seen
> AM> different standards groups, I am quite convinced that IETF
> AM> actually do a pretty good job with their specifications and the
> AM> thoroughness with which specifications are reviewed. I think it
> AM> is our responsibility to help set the standards so that people
> AM> can use them in most significant environments, rather than have us
> AM> ignore the issue and have people not only do it in less secure
> AM> ways, but also have different groups do the same job in
> AM> different ways.
>
> AM> [Note: I am not trying to say that IETF should set all standards
> AM> in the world, but it does need to acknowledge and react to the
> AM> needs of large and diverse groups. And the XML community is one
> AM> such group].
>
> AM> Comments?
> AM> Ambarish
>
>
> AM> ---------------------------------------------------------------------
> AM> Ambarish Malpani
> AM> Architect 650.567.5457
> AM> ValiCert, Inc. ambarish@valicert.com
> AM> 339 N. Bernardo Ave. http://www.valicert.com
> AM> Mountain View, CA 94043
>
>
>
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23759 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 14:32:07 -0800 (PST)
Received: from user-2injl3t.dialup.mindspring.com (user-2injl3t.dialup.mindspring.com [165.121.212.125]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA06175; Sat, 11 Nov 2000 17:39:14 -0500 (EST)
Date: Sat, 11 Nov 2000 17:40:44 -0500
From: Timothy Fisher <timothyf@mindspring.com>
X-Mailer: The Bat! (v1.46d) UNREG / CD5BF9353B3B7091
Reply-To: Timothy Fisher <timothyf@mindspring.com>
X-Priority: 3 (Normal)
Message-ID: <361031853857.20001111174044@mindspring.com>
To: "Phillip H. Griffin" <phil.griffin@asn-1.com>
CC: Rich Salz <rsalz@caveosystems.com>, Ambarish Malpani <ambarish@valicert.com>, "'Paul Koning'" <pkoning@ironstream.com>, <ietf-pkix@imc.org>
Subject: Re[2]: OCSP-X vs SCVP
In-reply-To: <3A0CBE45.C597640F@asn-1.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA7@exchange.valicert.com> <3A0C9B31.EE681811@caveosystems.com> <3A0CBE45.C597640F@asn-1.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Agreed there are currrently competing "schema/DTD" like efforts...
But this is exactly where standards would help... These issues
could certainly be addressed within PKI standards documents that were
based on XML.
--
Sincerely,
Timothy Fisher mailto:timothyf@mindspring.com
Friday, November 10, 2000, 10:34:29 PM, you wrote:
PHG> Rich Salz wrote:
>>
>> > Agreed, we are talking about XML vs DER.
>>
>> I don't think so. I think it's XML "versus" ASN.1 and DER: the whole system.
PHG> Well, if you're talking of politics I agree.
PHG> But if you only consider the technical aspects
PHG> then XML (markup) is only a textual transfer
PHG> syntax and DER is a binary transfer syntax.
>>
>> With the advent of XML-Schema, there is now an XML datatype description
>> language that supports complex types (struct), constraints, inheritance, etc.
>> (It's an interesting combination of pragmatism -- constraints can be expressed
>> as Perl regular expressions -- and elegance: an XML schema follows XML syntax
>> and is therefore a valid XML document.)
PHG> If there were but one XML schema life would
PHG> be easy. But there are many XML schema, and
PHG> more seem to be popping up in various XML
PHG> communities.
PHG> Currently, there are communities that wish
PHG> to use only XML markup and those that wish to
PHG> use XML markup with DTDs (which carry only
PHG> the structure component on ASN.1 notation,
PHG> but no data type or constraint information).
PHG> Then there are those relying on XML-schema
PHG> and those betting on some earlier schema
PHG> like derivative like BizTalk, and others in
PHG> the process of building DT4-DTDs (Data Types
PHG> for DTDs), etc.
PHG> As for constraint capabilities, ASN.1 has just
PHG> adopted a PATTERN constraint, which is used in
PHG> X9.68:
PHG> DNSName ::= VisibleString (SIZE(1..MAX))
PHG> (PATTERN "[A-Za-z0-9 .-]*")
PHG> There are several contraints available in ASN.1
PHG> that have no counterpart in XML-schema. And XML
PHG> schema is still under development, with notable
PHG> changes made just recently to accommodate the
PHG> XMLDSIG efforts.
>> I can see that XER is of interest to ASN.1 folks, but I dont' see any real
>> interest from the XML development community. It's useful to perserve existing
>> legacy (sic) ASN.1 definitions, but XML folks who want to describe data will
>> use DTD's and schema's. (If only because the specifications are free.) I
>> strongly believe the XML community will not enlarge the ASN.1 community.
>> /r$
PHG> Agreed. Free specifications are an important
PHG> consideration. The X.500 Group and the ASN.1
PHG> group are both working to have the current
PHG> ASN.1 specifications made free. Of course,
PHG> the ones that are being relied upon by the
PHG> IETF are already freely available.
PHG> Phil
PHG> ----
PHG> Phillip H. Griffin Griffin Consulting
PHG> http://asn-1.com Secure ASN.1 Design & Implementation
PHG> +1-919-832-7008 1625 Glenwood Avenue, Five Points
PHG> +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA
PHG> ------------------------------------------------------------
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23516 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 14:29:13 -0800 (PST)
Received: from user-2injl3t.dialup.mindspring.com (user-2injl3t.dialup.mindspring.com [165.121.212.125]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA15649; Sat, 11 Nov 2000 17:36:21 -0500 (EST)
Date: Sat, 11 Nov 2000 17:37:51 -0500
From: Timothy Fisher <timothyf@mindspring.com>
X-Mailer: The Bat! (v1.46d) UNREG / CD5BF9353B3B7091
Reply-To: Timothy Fisher <timothyf@mindspring.com>
X-Priority: 3 (Normal)
Message-ID: <1061031680638.20001111173751@mindspring.com>
To: Rich Salz <rsalz@caveosystems.com>
CC: Ambarish Malpani <ambarish@valicert.com>, "'Paul Koning'" <pkoning@ironstream.com>, <ietf-pkix@imc.org>
Subject: Re[2]: OCSP-X vs SCVP
In-reply-To: <3A0C9B31.EE681811@caveosystems.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA7@exchange.valicert.com> <3A0C9B31.EE681811@caveosystems.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Agreed.
--
Sincerely,
Timothy Fisher mailto:timothyf@mindspring.com
Friday, November 10, 2000, 8:04:49 PM, you wrote:
>> Agreed, we are talking about XML vs DER.
RS> I don't think so. I think it's XML "versus" ASN.1 and DER: the whole system.
RS> With the advent of XML-Schema, there is now an XML datatype description
RS> language that supports complex types (struct), constraints, inheritance, etc.
RS> (It's an interesting combination of pragmatism -- constraints can be expressed
RS> as Perl regular expressions -- and elegance: an XML schema follows XML syntax
RS> and is therefore a valid XML document.)
RS> I can see that XER is of interest to ASN.1 folks, but I dont' see any real
RS> interest from the XML development community. It's useful to perserve existing
RS> legacy (sic) ASN.1 definitions, but XML folks who want to describe data will
RS> use DTD's and schema's. (If only because the specifications are free.) I
RS> strongly believe the XML community will not enlarge the ASN.1 community.
RS> /r$
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23252 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 14:26:47 -0800 (PST)
Received: from user-2injl3t.dialup.mindspring.com (user-2injl3t.dialup.mindspring.com [165.121.212.125]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA22566; Sat, 11 Nov 2000 17:33:56 -0500 (EST)
Date: Sat, 11 Nov 2000 17:35:25 -0500
From: Timothy Fisher <timothyf@mindspring.com>
X-Mailer: The Bat! (v1.46d) UNREG / CD5BF9353B3B7091
Reply-To: Timothy Fisher <timothyf@mindspring.com>
X-Priority: 3 (Normal)
Message-ID: <621031534588.20001111173525@mindspring.com>
To: "Phillip H. Griffin" <phil.griffin@asn-1.com>
CC: ietf-pkix@imc.org
Subject: Re[2]: OCSP-X vs SCVP
In-reply-To: <3A0C5B08.2BB64606@asn-1.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA1@exchange.valicert.com> <14860.19395.882391.293192@pkoning.ironstream.com> <3A0C5B08.2BB64606@asn-1.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This is a step in the right direction, but I still believe that the
fundamental problem that many people have is with ASN1, and not just
the mechanism of encoding the syntax.
In an "Ideal" world for the e-business developers, ASN1 would go away
and PKI data would be designated by a series of PKI DTDs which would
become standardized.
--
Sincerely,
Timothy Fisher mailto:timothyf@mindspring.com
Friday, November 10, 2000, 3:31:04 PM, you wrote:
PHG> Paul Koning wrote:
>>
>> >>>>> "Ambarish" == Ambarish Malpani <ambarish@valicert.com> writes:
>>
>> Ambarish> Hi Guys, Just to keep things simple, it would be good to
>> Ambarish> break up this debate into 2 separate discussions:
>>
>> Ambarish> 1. Should PKIX protocols/work items support XML well or
>> Ambarish> should they just stay with ASN.1
>>
>> Are we talking about XML vs. ASN.1 or XML vs. BER/XER/*ER ? It
>> sounds more like the latter, and given that "ASN.1" is sometimes
>> mentioned when a more precise reference would be to
>> BER/DER/etc. instead, I wonder...
>>
>> paul
PHG> As very much of a side note, the group that works on the
PHG> ASN.1 standards is nearing consensus on how to approach
PHG> standardization of an ASN.1/XML capability. Formal work
PHG> will begin next meeting and likely conclude by the 2Q
PHG> next year. But the basic problem set has been under study
PHG> for well over a year and a half.
PHG> There are still some competing ideas, but I have proposed
PHG> recently and gotten some support for creating a default
PHG> XML markup associated with ASN.1 values. The markup would
PHG> be based on the structure and schema information (and the
PHG> identifier and type names) provided by ASN.1 specifications.
PHG> Further work would add the ability of the user to change or
PHG> augment the default markup.
PHG> This would allow an ASN.1 based protocol to encode data for
PHG> transfer using either text or binary encoding rules. For the
PHG> case of text transfer, there are proposals to support both
PHG> tagged (*ML markup) and untagged text. The association of
PHG> default markup with an ASN.1 specification would make it
PHG> possible for a sender to transfer data efficiently using
PHG> BER or PER, then decode the binary representation of the
PHG> values into a tagged or untagged text format for direct
PHG> display - no well formed checking or validation required,
PHG> as the act of ASN.1 encoding and decoding already performs
PHG> these tasks.
PHG> The idea is to layer *ML markup on top of ASN.1 which has
PHG> a single, mature schema, well defined canonical forms,
PHG> efficient encoding rules, and encoding control notation.
PHG> This approach avoids completely the moving target problems
PHG> we've continued to encounter when attempting to map ASN.1
PHG> schema into XML (DTDs, XML-schema, DT4-DTD, RELAX, BizTalk,
PHG> etc.).
PHG> Phil
PHG> ----
PHG> Phillip H. Griffin Griffin Consulting
PHG> http://asn-1.com Secure ASN.1 Design & Implementation
PHG> +1-919-832-7008 1625 Glenwood Avenue, Five Points
PHG> +1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA
PHG> ------------------------------------------------------------
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22975 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 14:23:17 -0800 (PST)
Received: from user-2injl3t.dialup.mindspring.com (user-2injl3t.dialup.mindspring.com [165.121.212.125]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA06413; Sat, 11 Nov 2000 17:30:24 -0500 (EST)
Date: Sat, 11 Nov 2000 17:31:54 -0500
From: Timothy Fisher <timothyf@mindspring.com>
X-Mailer: The Bat! (v1.46d) UNREG / CD5BF9353B3B7091
Reply-To: Timothy Fisher <timothyf@mindspring.com>
X-Priority: 3 (Normal)
Message-ID: <851031323845.20001111173154@mindspring.com>
To: Paul Koning <pkoning@ironstream.com>
CC: ambarish@valicert.com, ietf-pkix@imc.org
Subject: Re[2]: OCSP-X vs SCVP
In-reply-To: <14860.19395.882391.293192@pkoning.ironstream.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA1@exchange.valicert.com> <14860.19395.882391.293192@pkoning.ironstream.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I think that the discussion really should be XML vs. ASN1, and not
just XML vs. BER/DER/*ER.
--
Sincerely,
Timothy Fisher mailto:timothyf@mindspring.com
Friday, November 10, 2000, 2:25:55 PM, you wrote:
>>>>>> "Ambarish" == Ambarish Malpani <ambarish@valicert.com> writes:
PK> Ambarish> Hi Guys, Just to keep things simple, it would be good to
PK> Ambarish> break up this debate into 2 separate discussions:
PK> Ambarish> 1. Should PKIX protocols/work items support XML well or
PK> Ambarish> should they just stay with ASN.1
PK> Are we talking about XML vs. ASN.1 or XML vs. BER/XER/*ER ? It
PK> sounds more like the latter, and given that "ASN.1" is sometimes
PK> mentioned when a more precise reference would be to
PK> BER/DER/etc. instead, I wonder...
PK> paul
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22784 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 14:19:33 -0800 (PST)
Received: from user-2injl3t.dialup.mindspring.com (user-2injl3t.dialup.mindspring.com [165.121.212.125]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA22026; Sat, 11 Nov 2000 17:26:42 -0500 (EST)
Date: Sat, 11 Nov 2000 17:28:12 -0500
From: Timothy Fisher <timothyf@mindspring.com>
X-Mailer: The Bat! (v1.46d) UNREG / CD5BF9353B3B7091
Reply-To: Timothy Fisher <timothyf@mindspring.com>
X-Priority: 3 (Normal)
Message-ID: <771031101775.20001111172812@mindspring.com>
To: Ambarish Malpani <ambarish@valicert.com>
CC: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: Should PKIX protocols support XML well
In-reply-To: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ambarish,
I support your comments and think they they are well put...
Outside of the IETF, I know from personal experience that there is
a growing opinion that the PKI standards based on ASN1 are "behind the
times." Those of you who don't agree with that statement, please
don't argue the point to me, I am simply conveying what I feel is a
growing opinion.
The IETF would be wise to consider XML in future PKI work...
--
Sincerely,
Timothy Fisher mailto:timothyf@mindspring.com
Friday, November 10, 2000, 2:08:48 PM, you wrote:
AM> There are a bunch of industries/communities that are using XML
AM> throughout their systems - all their messages are in XML, all
AM> their development is in XML and XML is their chosen future
AM> direction.
AM> We may or may not agree about whether this is a wise decision, but
AM> that decision has been made and is one that we (PKIX) can not
AM> change.
AM> Now the question is, do we try and support such groups in their
AM> efforts or do we say: "Sorry, we think you did the wrong thing
AM> by not picking ASN.1, so go figure out how to do public key
AM> cryptography by yourself - we won't help"
AM> My personal bias is that if a significant percent of the world
AM> is headed towards XML, it makes more sense for us to support that
AM> group and make sure that when they do PKI, they do it in a
AM> secure way, rather than ignore that world and have them do PKI
AM> either insecurely, or in n different ways. After having seen
AM> different standards groups, I am quite convinced that IETF
AM> actually do a pretty good job with their specifications and the
AM> thoroughness with which specifications are reviewed. I think it
AM> is our responsibility to help set the standards so that people
AM> can use them in most significant environments, rather than have us
AM> ignore the issue and have people not only do it in less secure
AM> ways, but also have different groups do the same job in
AM> different ways.
AM> [Note: I am not trying to say that IETF should set all standards
AM> in the world, but it does need to acknowledge and react to the
AM> needs of large and diverse groups. And the XML community is one
AM> such group].
AM> Comments?
AM> Ambarish
AM> ---------------------------------------------------------------------
AM> Ambarish Malpani
AM> Architect 650.567.5457
AM> ValiCert, Inc. ambarish@valicert.com
AM> 339 N. Bernardo Ave. http://www.valicert.com
AM> Mountain View, CA 94043
Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22656 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 14:14:36 -0800 (PST)
Received: from user-2injl3t.dialup.mindspring.com (user-2injl3t.dialup.mindspring.com [165.121.212.125]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA10370; Sat, 11 Nov 2000 17:21:39 -0500 (EST)
Date: Sat, 11 Nov 2000 17:23:08 -0500
From: Timothy Fisher <timothyf@mindspring.com>
X-Mailer: The Bat! (v1.46d) UNREG / CD5BF9353B3B7091
Reply-To: Timothy Fisher <timothyf@mindspring.com>
X-Priority: 3 (Normal)
Message-ID: <1781030797378.20001111172308@mindspring.com>
To: =?ISO-8859-1?B?TWljaGFlbCBTdHL2ZGVy?= <michael@stroeder.com>
CC: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re[2]: OCSP-X vs SCVP
In-reply-To: <3A0BA070.8980607@stroeder.com>
References: <D44EACB40164D311BEF00090274EDCCACF8F59@sydneymail1.jp.zergo.com.au> <3A0B473B.A67F994@xcert.com> <3A0BA070.8980607@stroeder.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
A general comment:
A gradual move towards XML and away from ASN1 in the PKI world would
be a great benefit to the developer community and I believe the
e-business community at large...
XML would be a great step in opening this technology to a wider base
of expertise.
--
Sincerely,
Timothy Fisher mailto:timothyf@mindspring.com
Friday, November 10, 2000, 2:14:56 AM, you wrote:
MS> Marc Branchaud wrote:
>>
>> The non-PKI folk want their XML apps to use
>> PKI (as do the PKI folks, I might add), but they don't want to bloat their
>> apps with an ASN.1 toolkit.
MS> Most times it's easier to find a mature XML kit than a ASN.1 kit.
MS> But IMHO ASN.1 is not the main problem when deploying this
MS> X.509-based stuff.
MS> Ciao, Michael.
Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA29666 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 06:02:24 -0800 (PST)
From: rsalz@CaveoSystems.com
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 05515888; Sat, 11 Nov 2000 09:09:30 -0500 (EST)
Received: (from rsalz@localhost) by os390.caveosystems.com (8.9.3/8.9.3) id JAA11463; Sat, 11 Nov 2000 09:09:26 -0500
Date: Sat, 11 Nov 2000 09:09:26 -0500
Message-Id: <200011111409.JAA11463@os390.caveosystems.com>
To: phil.griffin@asn-1.com
Subject: Re: OCSP-X vs SCVP
Cc: ietf-pkix@imc.org
X-Loop-Detect: 1
>But if you only consider the technical aspects
>then XML (markup) is only a textual transfer
>syntax and DER is a binary transfer syntax.
I disagree, and that was the point of my note: XML-Schema is like ASN.1
Listing a datatype from the XML Digital Signature spec, a "Manifest"
is a set of "References" and may have an identifier:
<Manifest ID="rsalz.com:my-list-of-tbs-data">
<Reference>...</Reference>
...
</Manifest>
I can describe that in ASN.1:
Reference ::= SEQUENCE { ... }
Manifest ::= SEQUENCE {
References SEQUENCE OF Reference,
Id [0] EXPLICIT ID OPTIONAL
}
and I can describe that in XMLSchema:
<element name="Reference"> ... </element>
<element name="Manifest">
<complexType>
<sequence>
<element ref="ds:Reference" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional">
</complexType>
</element>
Certainly ASN.1 is older and parts are more stable, but it's also growing
(and has grown -- PKIX1Explicit88, e.g.). So is XMLSchema. For the
purposes of comparison, let's just call them equivalent.
>If there were but one XML schema life would
>be easy. But there are many XML schema, and
>more seem to be popping up in various XML
>communities.
That makes no more sense than saying there should be but one ASN.1 module.
I'm not advocating that the IETF, the Security Area or the PKIX WG "use"
XML (for some definition of use). I am trying to show that the XML
communities are working to define *everything* needed to describe and
exchange data. It might not make sense to use it -- I personally
see little point in rewriting X.509v3 datatypes in XML-Schema -- but
we should be aware of what's going on for if/when we do decide to work
in that space.
/r$
Received: from irwell.zetnet.co.uk (root@irwell.zetnet.co.uk [194.247.47.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA29043 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 05:53:49 -0800 (PST)
Received: from jeffdavis (man-a099.dialup.zetnet.co.uk [194.247.44.99]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA17074; Sat, 11 Nov 2000 14:00:46 GMT
X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a099.dialup.zetnet.co.uk [194.247.44.99] claimed to be jeffdavis
Message-ID: <002c01c04be7$991ac190$452cf7c2@zetnet.co.uk>
From: "Jeff Davis" <jeff.davis@zetnet.co.uk>
To: "Ambarish Malpani" <ambarish@valicert.com>, <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com>
Subject: Re: Should PKIX protocols support XML well
Date: Sat, 11 Nov 2000 13:56:49 -0000
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_0027_01C04BE7.3D422ED0"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
This is a multi-part message in MIME format.
------=_NextPart_000_0027_01C04BE7.3D422ED0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Ambarish,
I for one totally agree with you. We use XML extensively and wish to
move into using PKI within our development. If we could do that within
XML life would be that much better for us.
Jeff
----- Original Message -----
From: Ambarish Malpani <ambarish@valicert.com>
To: <ietf-pkix@imc.org>
Sent: Friday, November 10, 2000 7:08 PM
Subject: Should PKIX protocols support XML well
>
>
> There are a bunch of industries/communities that are using XML
> throughout their systems - all their messages are in XML, all
> their development is in XML and XML is their chosen future
> direction.
>
> We may or may not agree about whether this is a wise decision, but
> that decision has been made and is one that we (PKIX) can not
> change.
>
> Now the question is, do we try and support such groups in their
> efforts or do we say: "Sorry, we think you did the wrong thing
> by not picking ASN.1, so go figure out how to do public key
> cryptography by yourself - we won't help"
>
> My personal bias is that if a significant percent of the world
> is headed towards XML, it makes more sense for us to support that
> group and make sure that when they do PKI, they do it in a
> secure way, rather than ignore that world and have them do PKI
> either insecurely, or in n different ways. After having seen
> different standards groups, I am quite convinced that IETF
> actually do a pretty good job with their specifications and the
> thoroughness with which specifications are reviewed. I think it
> is our responsibility to help set the standards so that people
> can use them in most significant environments, rather than have us
> ignore the issue and have people not only do it in less secure
> ways, but also have different groups do the same job in
> different ways.
>
> [Note: I am not trying to say that IETF should set all standards
> in the world, but it does need to acknowledge and react to the
> needs of large and diverse groups. And the XML community is one
> such group].
>
> Comments?
> Ambarish
>
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect 650.567.5457
> ValiCert, Inc. ambarish@valicert.com
> 339 N. Bernardo Ave. http://www.valicert.com
> Mountain View, CA 94043
>
>
>
------=_NextPart_000_0027_01C04BE7.3D422ED0
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwzCCAjww
ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ
BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs
aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea
BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg
1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm
lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z
SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4
RTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy
MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL
uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj
zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYw
RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
AgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/
LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDl
X4KmsaiSxVhqwY0DPOvDzQWikK5uMIIETTCCA7agAwIBAgIQat1MGeiCubKpRtmanUnH8TANBgkq
hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu
IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg
SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMDA0MjYw
MDAwMDBaFw0wMTA0MjYyMzU5NTlaMIIBFTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV
BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw
b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0
IEZ1bGwgU2VydmljZTETMBEGA1UEAxQKSmVmZiBEYXZpczEmMCQGCSqGSIb3DQEJARYXamVmZi5k
YXZpc0B6ZXRuZXQuY28udWswXDANBgkqhkiG9w0BAQEFAANLADBIAkEA3N/fjyGwWl7qRo9/AMUh
zTw4QHJcZYUAaOUNCPc8lrTkRzRzfxnXzKlFMiWZ8qXWRNn3ogrnz+ckfwSxvbWGqQIDAQABo4IB
JjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBwEIMCowKAYIKwYBBQUHAgEW
HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgB
hvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5
ZGE3NWJjNGJjOTcwMTc0N2RhNWMxZTMxNDFiZWFkYjJiZDI4YmU1MTdhYzZhOThiMDExNDk5Y2Ey
YjI0N2Y5ZjNlYTQ1MGQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v
Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQBIpsjsnaTekorJTnURkiZ6qlEao4J5cgKDbKW6
cA3CW2LXuZsugj5hQ/lUzYMjY6jSKiM7WquT3x33xVAnwbGuHl4GXeJdZWOGhetx0+BL4J8k7cJ4
zITXqBoF4TpTjN2H8KyicBeuRsO1KIW1JlQDksVI6xG6Ogg0pCcvhp4z0DGCAcYwggHCAgEBMIHh
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk
dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBq3UwZ6IK5sqlG2ZqdScfxMAkG
BSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDEx
MTExMzU2NDlaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJKoZIhvcNAQkEMRYE
FMABiiwsy4uWiJhdNVAavBxLSYW/MA0GCSqGSIb3DQEBAQUABECihgeGA3LRWz0aaj3NIUH9CuW9
0bXrBg4DLsBInN+Vg2hV4rZat8586YJet+f0Rs3TJEHzfhyOXSv9mKo08RowAAAAAAAA
------=_NextPart_000_0027_01C04BE7.3D422ED0--
Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA15033 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 02:26:31 -0800 (PST)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <W1ALCC1L>; Sat, 11 Nov 2000 05:30:49 -0500
Message-ID: <A105E1C02F5DD31181A500508B5519EC519AAC@blue.identrus.com>
From: Khaja Ahmed <Khaja.Ahmed@identrus.com>
To: "'Anders Rundgren '" <anders.rundgren@telia.com>, "'Rich Salz '" <rsalz@caveosystems.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Sat, 11 Nov 2000 05:30:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04BCA.7590A1D0"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C04BCA.7590A1D0
Content-Type: text/plain;
charset="iso-8859-1"
> When I some days ago launched the idea that AC's should (or could) be
> based on XML schemas there were hardly any sentiment for that.
> Some even cocluded that XML was not a PKIX-item!
> Now I see a lot of XML "promotion" in an other PKIX-area which is
> interesting but slightly puzzling.
> IMO ACs have at least the same "informational content" as OCSP-X and
> SCVP. Each AC "authorization profile", "receipt" or "ticket" ought
> to be just perfect to express as an XML schema. Wouldn't it?
It would. Indeed that is precisely the thing needed for a distributed
authorization management solution being contemplated in some very large
applications. If you did not get support for it previously that is
regrettable. I certainly would support that wholeheartedly.
Khaja
------_=_NextPart_001_01C04BCA.7590A1D0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: OCSP-X vs SCVP</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>> When I some days ago launched the idea that AC's =
should (or could) be</FONT>
<BR><FONT SIZE=3D2>> based on XML schemas there were hardly any =
sentiment for that.</FONT>
</P>
<P><FONT SIZE=3D2>> Some even cocluded that XML was not a =
PKIX-item!</FONT>
</P>
<P><FONT SIZE=3D2>> Now I see a lot of XML "promotion" in =
an other PKIX-area which is</FONT>
<BR><FONT SIZE=3D2>> interesting but slightly puzzling.</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>> IMO ACs have at least the same =
"informational content" as OCSP-X and</FONT>
<BR><FONT SIZE=3D2>> SCVP. Each AC "authorization =
profile", "receipt" or "ticket" ought </FONT>
<BR><FONT SIZE=3D2>> to be just perfect to express as an XML =
schema. Wouldn't it?</FONT>
</P>
<P><FONT SIZE=3D2>It would. Indeed that is precisely the thing =
needed for a distributed authorization management solution being =
contemplated in some very large applications. If you did not get =
support for it previously that is regrettable. I certainly would =
support that wholeheartedly.</FONT></P>
<P><FONT SIZE=3D2>Khaja</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C04BCA.7590A1D0--
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08903 for <ietf-pkix@imc.org>; Sat, 11 Nov 2000 01:13:02 -0800 (PST)
Received: from mega (t4o69p51.telia.com [62.20.145.171]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id KAA12740; Sat, 11 Nov 2000 10:20:08 +0100 (CET)
Message-ID: <000d01c04bc0$65352680$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Rich Salz" <rsalz@caveosystems.com>
Cc: <ietf-pkix@imc.org>
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA7@exchange.valicert.com> <3A0C9B31.EE681811@caveosystems.com>
Subject: Re: OCSP-X vs SCVP
Date: Sat, 11 Nov 2000 10:18:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA08904
Rich (et al).
> With the advent of XML-Schema, there is now an XML datatype description
> language that supports complex types (struct), constraints, inheritance, etc.
> (It's an interesting combination of pragmatism -- constraints can be expressed
> as Perl regular expressions -- and elegance: an XML schema follows XML syntax
> and is therefore a valid XML document.)
I don't get it.
When I some days ago launched the idea that AC's should (or could) be based on XML schemas
there were hardly any sentiment for that.
Some even cocluded that XML was not a PKIX-item!
Now I see a lot of XML "promotion" in an other PKIX-area which is interesting but slightly puzzling.
IMO ACs have at least the same "informational content" as OCSP-X and SCVP.
Each AC "authorization profile", "receipt" or "ticket" ought to be just perfect to express
as an XML schema. Wouldn't it?
Anders
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA11934 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 19:24:18 -0800 (PST)
Received: from asn-1.com (user-2ivf7s1.dialup.mindspring.com [165.247.159.129]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA19552; Fri, 10 Nov 2000 22:31:21 -0500 (EST)
Message-ID: <3A0CBE45.C597640F@asn-1.com>
Date: Fri, 10 Nov 2000 22:34:29 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Rich Salz <rsalz@caveosystems.com>
CC: Ambarish Malpani <ambarish@valicert.com>, "'Paul Koning'" <pkoning@ironstream.com>, ietf-pkix@imc.org
Subject: Re: OCSP-X vs SCVP
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA7@exchange.valicert.com> <3A0C9B31.EE681811@caveosystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rich Salz wrote:
>
> > Agreed, we are talking about XML vs DER.
>
> I don't think so. I think it's XML "versus" ASN.1 and DER: the whole system.
Well, if you're talking of politics I agree.
But if you only consider the technical aspects
then XML (markup) is only a textual transfer
syntax and DER is a binary transfer syntax.
>
> With the advent of XML-Schema, there is now an XML datatype description
> language that supports complex types (struct), constraints, inheritance, etc.
> (It's an interesting combination of pragmatism -- constraints can be expressed
> as Perl regular expressions -- and elegance: an XML schema follows XML syntax
> and is therefore a valid XML document.)
If there were but one XML schema life would
be easy. But there are many XML schema, and
more seem to be popping up in various XML
communities.
Currently, there are communities that wish
to use only XML markup and those that wish to
use XML markup with DTDs (which carry only
the structure component on ASN.1 notation,
but no data type or constraint information).
Then there are those relying on XML-schema
and those betting on some earlier schema
like derivative like BizTalk, and others in
the process of building DT4-DTDs (Data Types
for DTDs), etc.
As for constraint capabilities, ASN.1 has just
adopted a PATTERN constraint, which is used in
X9.68:
DNSName ::= VisibleString (SIZE(1..MAX))
(PATTERN "[A-Za-z0-9 .-]*")
There are several contraints available in ASN.1
that have no counterpart in XML-schema. And XML
schema is still under development, with notable
changes made just recently to accommodate the
XMLDSIG efforts.
> I can see that XER is of interest to ASN.1 folks, but I dont' see any real
> interest from the XML development community. It's useful to perserve existing
> legacy (sic) ASN.1 definitions, but XML folks who want to describe data will
> use DTD's and schema's. (If only because the specifications are free.) I
> strongly believe the XML community will not enlarge the ASN.1 community.
> /r$
Agreed. Free specifications are an important
consideration. The X.500 Group and the ASN.1
group are both working to have the current
ASN.1 specifications made free. Of course,
the ones that are being relied upon by the
IETF are already freely available.
Phil
----
Phillip H. Griffin Griffin Consulting
http://asn-1.com Secure ASN.1 Design & Implementation
+1-919-832-7008 1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA09847 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 16:55:27 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 05449342; Fri, 10 Nov 2000 20:02:17 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-76-88.bellatlantic.net [141.154.76.88]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id UAA10755; Fri, 10 Nov 2000 20:02:13 -0500
Message-ID: <3A0C9B31.EE681811@caveosystems.com>
Date: Fri, 10 Nov 2000 20:04:49 -0500
From: Rich Salz <rsalz@caveosystems.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani <ambarish@valicert.com>
CC: "'Paul Koning'" <pkoning@ironstream.com>, ietf-pkix@imc.org
Subject: Re: OCSP-X vs SCVP
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA7@exchange.valicert.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
> Agreed, we are talking about XML vs DER.
I don't think so. I think it's XML "versus" ASN.1 and DER: the whole system.
With the advent of XML-Schema, there is now an XML datatype description
language that supports complex types (struct), constraints, inheritance, etc.
(It's an interesting combination of pragmatism -- constraints can be expressed
as Perl regular expressions -- and elegance: an XML schema follows XML syntax
and is therefore a valid XML document.)
I can see that XER is of interest to ASN.1 folks, but I dont' see any real
interest from the XML development community. It's useful to perserve existing
legacy (sic) ASN.1 definitions, but XML folks who want to describe data will
use DTD's and schema's. (If only because the specifications are free.) I
strongly believe the XML community will not enlarge the ASN.1 community.
/r$
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07521 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 14:42:34 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA185694; Fri, 10 Nov 2000 17:49:06 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id RAA71694; Fri, 10 Nov 2000 17:48:35 -0500
Importance: Normal
Subject: Re: Holder
To: Steve Hanna <steve.hanna@sun.com>
Cc: ietf-pkix@imc.org
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFE309F0CD.FAD54440-ON85256993.00595781@somers.hqregion.ibm.com>
From: "Tom Gindin/Watson/IBM" <tgindin@us.ibm.com>
Date: Fri, 10 Nov 2000 17:49:34 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.5 |September 22, 2000) at 11/10/2000 05:49:39 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
The primary use I can think of for format 7, 9, or 11 is to permit an
AC to accompany (or simply be stored with) a signed document, transaction,
or message without requiring the PKC to do so. The RP can then look up the
PKC. As I have stated before, in any case like this format 11 or format 9
is preferable to format 5. Formats 4 and 5 are appropriate when the PKC
accompanies the AC or precedes it in a protocol, but not otherwise.
Since format 9 (or format 11) is preferable to format 5 when the AC is
sent or stored independently of the PKC and also carries out all the
functions of format 5, I would replace your references to format 5 by
references to format 9 (or format 11). Formats 2, 4, and 9 make a
reasonable minimal set, as do 2, 4, and 11.
Tom Gindin
Steve Hanna <steve.hanna@sun.com> on 11/10/2000 10:56:55 AM
To: ietf-pkix@imc.org
cc:
Subject: Re: Holder
Well, my list of scenarios does not seem to be helping us resolve this
issue.
I will make a specific proposal, seeking comments or consensus. Since
none of the scenarios demonstrates a need for hints in Holder formats
that include the objectDigestInfo component, I propose that we adopt the
following recommendation, which would be incorporated into the next
version of ac509 (along with text explaining the various formats, how
they must be handled for validation purposes, and why each one might be
preferred to the others).
AC issuers SHOULD use only formats 2, 4, or 5. They MAY use other
formats, as necessary. AC verifiers SHOULD support formats 2, 4, and
5 (subject to specific requirements and configuration). They MAY
support other formats.
I welcome comments from others on this proposal. A good argument can be
made for replacing format 5 with format 9, if only for debugging
purposes. But I'd rather not recommend support for both, if possible.
-Steve
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06846 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 14:21:17 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G3T00E01YFARL@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 10 Nov 2000 14:28:23 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G3T00DKVYFAYT@ext-mail.valicert.com>; Fri, 10 Nov 2000 14:28:22 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NLFG8>; Fri, 10 Nov 2000 14:26:30 -0800
Content-return: allowed
Date: Fri, 10 Nov 2000 14:26:20 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: OCSP-X vs SCVP
To: "'Paul Koning'" <pkoning@ironstream.com>
Cc: ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E152FA7@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Agreed, we are talking about XML vs DER.
I don't know that XER has enough traction/usage to make it a
viable solution in XML land (even though it would make things
very simple in the ASN.1 land).
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Paul Koning [mailto:pkoning@ironstream.com]
> Sent: Friday, November 10, 2000 11:26 AM
> To: ambarish@valicert.com
> Cc: ietf-pkix@imc.org
> Subject: RE: OCSP-X vs SCVP
>
>
> >>>>> "Ambarish" == Ambarish Malpani <ambarish@valicert.com> writes:
>
> Ambarish> Hi Guys, Just to keep things simple, it would be good to
> Ambarish> break up this debate into 2 separate discussions:
>
> Ambarish> 1. Should PKIX protocols/work items support XML well or
> Ambarish> should they just stay with ASN.1
>
> Are we talking about XML vs. ASN.1 or XML vs. BER/XER/*ER ? It
> sounds more like the latter, and given that "ASN.1" is sometimes
> mentioned when a more precise reference would be to
> BER/DER/etc. instead, I wonder...
>
> paul
>
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05689 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 13:36:58 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G3T00E01WDDJI@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 10 Nov 2000 13:44:01 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G3T00ECSWDD2Z@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 10 Nov 2000 13:44:01 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NLFCB>; Fri, 10 Nov 2000 13:42:09 -0800
Content-return: allowed
Date: Fri, 10 Nov 2000 13:42:07 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E152FA4@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Here are some of my thoughts on why I think SCVP is the right
way to go ahead with remote path processing (RPP), rather than
creating a new version of OCSP (OCSPv2) and then defining OCSPpath
and OCSPvalid.
Issues with OCSPv2
------------------
- It causes uncertainity and concern about OCSP, even though there
aren't really any problems with the protocol itself
- It will cause a bunch of interoperability issue with OCSP for
certificate status checks, because now you can identify a
certificate in many different ways
- The semantics of what a server is required to do for a plain
OCSP request are unclear - does it need to check the expiry of
the certificate, what about the signature, etc on the cert?
- It is unclear to me that the right thing to do is to change a
stable protocol just to add a bunch of new functionality, that
doesn't really do anything more for the base protocol.
- If we go this route, we will take a lot longer to actually
reach a usable spec for RPP, because our first 12 months will
be spend debating the changes to OCSP
- I would actually like the current OCSP, with some minor
clarifications and changing of the required signature algorithm
to RSA (from DSA), to continue on the standards track, we have
actually had a reasonable amount of interop testing on it
Issues with this approach
-------------------------
- It is very unclear to me that OCSPvalid is trying to do the
same thing as OCSP. So why is there such a strong interest in
doing it as an extension to OCSP - I believe it will actually
cause more confusion than clarification, where when somebody
says they support OCSP and another person wants to use OCSP, there
is no guarantee that they are talking about the same thing.
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04433 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 12:48:30 -0800 (PST)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA04980 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 12:51:21 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <WQQYJKW7>; Fri, 10 Nov 2000 12:55:07 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4017CE6A8@vhqpostal.verisign.com>
From: Michael Myers <MMyers@verisign.com>
To: ietf-pkix@imc.org
Subject: RE: DPV vs SCVP
Date: Fri, 10 Nov 2000 12:55:04 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Russ, thanks for getting this debate kicked off. After all the work various
of us have put into this issue, I was beginning to think no one cared.
All, as to the debate:
Let's hear from everybody before we make a decision.
----------------------------------------------------
Thanks to all who have read the IDs and provided comments (especially Denis
Pinkas). But since active WG members have taken time out of their busy
schedules to improve the IDs, I think it only fair that final judgement be
witheld until those contributions are folded into a revised version for our
consideration in San Diego. At that time it might be more appropriate to
decide between the two.
It's DPV vs. SCVP
-----------------
OCSP-X has expired; DPV and DPD replace that initial work. The requirement
we're all most concerned about is delegated path validation (although
delegated path discovery has it's use). So it really comes down to DPV+DPD
vs. SCVP since OCSP is already RFC 2560. DPV is little more than an OID and
a corresponding semantic; it simply puts more meat behind 2560's notion of
"good". DPD is only a bit more along these same lines of design.
They're going to do it anyway.
------------------------------
DPV and DPD are nothing more than proposed standard extensions to the
already existing extension hooks in 2560. Given the availablility of those
hooks, there's nothing to stop any environment from doing precisely this, if
only to establish a closed system-level solution. Given that, it's better
that we take responsible action to promote Internet interoperability via a
standard means of doing so in the event that such closed environments may
someday find it useful to interoperate.
OCSPv2 is separable to the DPV vs. SCVP question
------------------------------------------------
Carlisle, Rich Ankney and I separately proposed OCSPv2. At its core, this
is simply an expansion of certificate identification syntax to accomodate
well-known use cases of the existing RFC 2560. It's really nothing more
than:
ReqCert ::= CHOICE {
certID CertID,
issuerSerial [0] IssuerandSerialNumber,
pKCert [1] Certificate,
name [2] GeneralName }
where in 2560 we simply have:
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
There's also a version number delta and corresponding guidance when to use a
given version number.
The lack of these alternatives is a long-standing criticism of 2560 and will
be fixed regardless of the outcome of the DPV vs. SCVP debate. Again, many
thanks to Denis Pinkas for his detailed, thoughtful and constructive
commentary on the OCSPv2 ID. I'll be bringing this up in a totally separate
thread from the DPV vs. SCVP discussion to resolve the MUSTs related to
supporting these various identification schemes.
XML is a whole new ballgame
---------------------------
It's true that the OCSPv2, DPV and DPD IDs don't address XML. There are two
reasons for this. First, there can be no doubt that XML can be an useful
PKI delivery platform. Khaja Ahmed's recent analysis said it well. But
there's probably going to be many competeting proposals addressing this
need. Secondly, considering XML only in the context of delegated path
validation ignores the full set of certificate lifecycle needs (e.g.
enrollment, renewal and revocation) that must be met to fully deliver on the
XML+PKI "vision".
In sum, it's quite possible that XML-based status needs are better met by a
tighter integration with business practices than is currently enabled by
ASN.1 based solutions. We can however predict with a reliable degree of
accuracy how an ASN.1-based solution integrates at least to existing
PKI-related protocols. Hence the DPV/DPD proposals chose to define a very
simple means by which a solution to these pressing certificate status needs
can be met with maximal reuse of existing ASN.1 investments, leaving the way
clear for XML+PKI to take its own course.
Best regards to all,
Mike
Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02397 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 12:20:46 -0800 (PST)
Received: from asn-1.com (user-2ivf1jg.dialup.mindspring.com [165.247.134.112]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA24067 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 15:27:51 -0500 (EST)
Message-ID: <3A0C5B08.2BB64606@asn-1.com>
Date: Fri, 10 Nov 2000 15:31:04 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: OCSP-X vs SCVP
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA1@exchange.valicert.com> <14860.19395.882391.293192@pkoning.ironstream.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Paul Koning wrote:
>
> >>>>> "Ambarish" == Ambarish Malpani <ambarish@valicert.com> writes:
>
> Ambarish> Hi Guys, Just to keep things simple, it would be good to
> Ambarish> break up this debate into 2 separate discussions:
>
> Ambarish> 1. Should PKIX protocols/work items support XML well or
> Ambarish> should they just stay with ASN.1
>
> Are we talking about XML vs. ASN.1 or XML vs. BER/XER/*ER ? It
> sounds more like the latter, and given that "ASN.1" is sometimes
> mentioned when a more precise reference would be to
> BER/DER/etc. instead, I wonder...
>
> paul
As very much of a side note, the group that works on the
ASN.1 standards is nearing consensus on how to approach
standardization of an ASN.1/XML capability. Formal work
will begin next meeting and likely conclude by the 2Q
next year. But the basic problem set has been under study
for well over a year and a half.
There are still some competing ideas, but I have proposed
recently and gotten some support for creating a default
XML markup associated with ASN.1 values. The markup would
be based on the structure and schema information (and the
identifier and type names) provided by ASN.1 specifications.
Further work would add the ability of the user to change or
augment the default markup.
This would allow an ASN.1 based protocol to encode data for
transfer using either text or binary encoding rules. For the
case of text transfer, there are proposals to support both
tagged (*ML markup) and untagged text. The association of
default markup with an ASN.1 specification would make it
possible for a sender to transfer data efficiently using
BER or PER, then decode the binary representation of the
values into a tagged or untagged text format for direct
display - no well formed checking or validation required,
as the act of ASN.1 encoding and decoding already performs
these tasks.
The idea is to layer *ML markup on top of ASN.1 which has
a single, mature schema, well defined canonical forms,
efficient encoding rules, and encoding control notation.
This approach avoids completely the moving target problems
we've continued to encounter when attempting to map ASN.1
schema into XML (DTDs, XML-schema, DT4-DTD, RELAX, BizTalk,
etc.).
Phil
----
Phillip H. Griffin Griffin Consulting
http://asn-1.com Secure ASN.1 Design & Implementation
+1-919-832-7008 1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax] Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01748; Fri, 10 Nov 2000 12:01:54 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0501045ab63206422417@[165.227.249.17]>
In-Reply-To: <001f01c04b4e$5b82e090$0442a296@labsec.inf.ufsc.br>
References: <001f01c04b4e$5b82e090$0442a296@labsec.inf.ufsc.br>
Date: Fri, 10 Nov 2000 12:09:01 -0800
To: "Augusto Jun Devegili" <devegili@inf.ufsc.br>, <ietf-pkix@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Doubt regarding OIDs
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 5:42 PM -0200 11/10/00, Augusto Jun Devegili wrote:
>Where can I possibly find a list of OIDs (and the objects they identify)
>defined by PKIX?
See the PKIX WG web page at <http://www.imc.org/ietf-pkix/>. The
information you want is near the bottom of the page.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01617 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 11:57:09 -0800 (PST)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP for <ietf-pkix@imc.org> id A5ACC15532; Fri, 10 Nov 2000 15:03:45 -0500 (EST)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 60B527C0E8 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 15:03:45 -0500 (EST)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <WMP244ZF>; Fri, 10 Nov 2000 15:03:51 -0500
Message-ID: <AAD0807E1794D311A54000A0C99609B916512C@macertco-srv1.ma.certco.com>
From: "Tiernan, Tim" <tiernant@CertCo.com>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: unsubscribe
Date: Fri, 10 Nov 2000 15:03:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Received: from inf.ufsc.br (euryale.inf.ufsc.br [150.162.60.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00747 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 11:34:34 -0800 (PST)
Received: from blowfish ([150.162.66.4]) by inf.ufsc.br (8.9.3/8.9.3) with SMTP id RAA181890 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 17:44:59 -0300
Message-ID: <001f01c04b4e$5b82e090$0442a296@labsec.inf.ufsc.br>
From: "Augusto Jun Devegili" <devegili@inf.ufsc.br>
To: <ietf-pkix@imc.org>
Subject: Doubt regarding OIDs
Date: Fri, 10 Nov 2000 17:42:27 -0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Dear sirs,
Where can I possibly find a list of OIDs (and the objects they identify)
defined by PKIX?
Thanks in advance,
Best regards,
Augusto Jun Devegili
Received: from jlc.net (3ff83a80.dsl.flashcom.net [63.248.58.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29263 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 11:18:53 -0800 (PST)
Received: (from pkoning@localhost) by jlc.net (8.9.3/8.8.7) id OAA01533; Fri, 10 Nov 2000 14:25:57 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14860.19395.882391.293192@pkoning.ironstream.com>
Date: Fri, 10 Nov 2000 14:25:55 -0500 (EST)
From: Paul Koning <pkoning@ironstream.com>
To: ambarish@valicert.com
Cc: ietf-pkix@imc.org
Subject: RE: OCSP-X vs SCVP
References: <613B3C619C9AD4118C4E00B0D03E7C3E152FA1@exchange.valicert.com>
X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid
>>>>> "Ambarish" == Ambarish Malpani <ambarish@valicert.com> writes:
Ambarish> Hi Guys, Just to keep things simple, it would be good to
Ambarish> break up this debate into 2 separate discussions:
Ambarish> 1. Should PKIX protocols/work items support XML well or
Ambarish> should they just stay with ASN.1
Are we talking about XML vs. ASN.1 or XML vs. BER/XER/*ER ? It
sounds more like the latter, and given that "ASN.1" is sometimes
mentioned when a more precise reference would be to
BER/DER/etc. instead, I wonder...
paul
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27780 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 11:05:44 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Nov 2000 19:10:48 UT
Received: from exrsa01.rsa.com (exrsa01.securitydynamics.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA24926 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 14:12:49 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2650.21) id <WN15YXLP>; Fri, 10 Nov 2000 11:12:49 -0800
Message-ID: <E7B6CB80230AD31185AD0008C7EBC4D28213E6@exrsa01.rsa.com>
From: "Kingdon, Kevin" <kevin@rsasecurity.com>
To: ietf-pkix <ietf-pkix@imc.org>
Subject: RE: Extended Key Usage and CP extensions (path validation)
Date: Fri, 10 Nov 2000 11:12:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
I would pick option 2 below. Option 1 doesn't allow for future situations
where a new EKU type could apply to the CA key itself. In moderate-to-deep
CA hierarchies, it is useful to be able to constrain the subordinate CAs. If
we need to, we could also constrain the basic key usage extension in a
similar way.
Kevin W. Kingdon
RSA Security, Inc.
-----Original Message-----
From: Tom Gindin/Watson/IBM [mailto:tgindin@us.ibm.com]
Sent: Friday, November 10, 2000 8:38 AM
To: Jean-Marc Desperrier
Cc: ietf-pkix
Subject: Re: Extended Key Usage and CP extensions (path validation)
IMHO the CP extension is not a good place for this, since the set of
policy OID's is not standardized and the OID's are not related to those for
EKU. That leaves us with three basic possibilities, since EKU with its
normal meaning is not very useful in CA certificates:
1 Define EKU as having its current meaning when it appears in an EE
certificate, and as a constraint when it appears in a CA certificate.
Thus, if an EE certificate is issued by a CA certificate with an EKU
extension, it may not have any EKU value not included in the CA
certificate's EKU extension. This matches your suggestion.
2 Deprecate EKU in CA certificates, and define an EKU constraint
extension. Either this would be a SET OF (or SEQUENCE OF) OID's, with the
same meaning as in case 1, or it would be defined as a CHOICE between
included and excluded, with included being a SET or SEQUENCE of OID's with
the same meaning as in case 1 and excluded being a SET or SEQUENCE of OID's
which may not appear in the EKU of any EE certificate descended from this
one.
3 Deprecate EKU in CA certificates, and declare that the function is not
really needed. One argument in favor of this is that there is no way to
constrain a CA from issuing a certificate with most of the KeyUsage flags
either, and NR is as strong a case for delegation constraint as most
currently assigned EKU values.
Tom Gindin
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27617 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 11:03:44 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G3T00D01PA1ER@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 10 Nov 2000 11:10:49 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G3T00DA8PA11Z@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 10 Nov 2000 11:10:49 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NL12M>; Fri, 10 Nov 2000 11:08:57 -0800
Content-return: allowed
Date: Fri, 10 Nov 2000 11:08:48 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: Should PKIX protocols support XML well
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E152FA2@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
There are a bunch of industries/communities that are using XML
throughout their systems - all their messages are in XML, all
their development is in XML and XML is their chosen future
direction.
We may or may not agree about whether this is a wise decision, but
that decision has been made and is one that we (PKIX) can not
change.
Now the question is, do we try and support such groups in their
efforts or do we say: "Sorry, we think you did the wrong thing
by not picking ASN.1, so go figure out how to do public key
cryptography by yourself - we won't help"
My personal bias is that if a significant percent of the world
is headed towards XML, it makes more sense for us to support that
group and make sure that when they do PKI, they do it in a
secure way, rather than ignore that world and have them do PKI
either insecurely, or in n different ways. After having seen
different standards groups, I am quite convinced that IETF
actually do a pretty good job with their specifications and the
thoroughness with which specifications are reviewed. I think it
is our responsibility to help set the standards so that people
can use them in most significant environments, rather than have us
ignore the issue and have people not only do it in less secure
ways, but also have different groups do the same job in
different ways.
[Note: I am not trying to say that IETF should set all standards
in the world, but it does need to acknowledge and react to the
needs of large and diverse groups. And the XML community is one
such group].
Comments?
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26661 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 10:49:25 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G3T00D01OM59Y@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 10 Nov 2000 10:56:29 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G3T00D4MOM43Q@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 10 Nov 2000 10:56:29 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NL1FJ>; Fri, 10 Nov 2000 10:54:37 -0800
Content-return: allowed
Date: Fri, 10 Nov 2000 10:54:33 -0800
From: Ambarish Malpani <ambarish@valicert.com>
Subject: RE: OCSP-X vs SCVP
To: ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E152FA1@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Hi Guys,
Just to keep things simple, it would be good to break up this
debate into 2 separate discussions:
1. Should PKIX protocols/work items support XML well or should
they just stay with ASN.1
2. Which is a better way of doing remote path processing:
a. SCVP
b. OCSPv2 with OCSP-valid and OCSP-path
I will follow up with posts on the two topics.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25721 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 10:23:27 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 82A84683BD for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 08:14:57 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A0BA070.8980607@stroeder.com>
Date: Fri, 10 Nov 2000 08:14:56 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: OCSP-X vs SCVP
References: <D44EACB40164D311BEF00090274EDCCACF8F59@sydneymail1.jp.zergo.com.au> <3A0B473B.A67F994@xcert.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Marc Branchaud wrote:
>
> The non-PKI folk want their XML apps to use
> PKI (as do the PKI folks, I might add), but they don't want to bloat their
> apps with an ASN.1 toolkit.
Most times it's easier to find a mature XML kit than a ASN.1 kit.
But IMHO ASN.1 is not the main problem when deploying this
X.509-based stuff.
Ciao, Michael.
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25720 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 10:23:27 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 8BCB7683C0 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 08:20:15 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A0BA1AE.CB48F18E@stroeder.com>
Date: Fri, 10 Nov 2000 08:20:14 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: OCSP-X vs SCVP
References: <D44EACB40164D311BEF00090274EDCCACF8F95@sydneymail1.jp.zergo.com.au> <p05010443b63106d22030@[165.227.249.17]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Paul Hoffman / IMC wrote:
>
> At 12:06 PM +1100 11/10/00, Michael Zolotarev wrote:
> >
> >MArk, this is really speculative thing to say... I don't buy it as an
> >argument, sorry.
>
> It is not speculative. There have been people on this mailing list
> who have said that they want an XML-based solution. Telling them that
> you don't buy their opinion as an argument will tend to cause them
> not to contribute again, yes?
Exactly.
And they will end up developing applications which are ignoring many
aspects defined by the PKIX working group.
Ciao, Michael.
Received: from edelweb.fr ([212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16556 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 09:07:28 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA03847; Fri, 10 Nov 2000 18:14:32 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 10 Nov 2000 18:14:32 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA14018; Fri, 10 Nov 2000 18:14:31 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA00947; Fri, 10 Nov 2000 18:14:30 +0100 (MET)
Date: Fri, 10 Nov 2000 18:14:30 +0100 (MET)
Message-Id: <200011101714.SAA00947@emeriau.edelweb.fr>
To: Peter.Sylvester@EdelWeb.fr, ietf-pkix@imc.org, frankb@valicert.com
Subject: RE: OCSP-X vs SCVP
> It seems to me that this discussion has focused on encoding and syntax, but
> not on the semantics of path creation and validation. In other words, what
> are the requirements for server-based (including delegated) path creation
> (or discovery) and validation.
Right, one should concentrate on the requirements.
>From your wording, it seems to me that you mainly interested in one use case,
i.e., determining the validity of a cert in order either to verify a signature
or authentication or to verify the validity of an encryption cert before
using it?
> I would like to see PKIX's solution support the ability for a client to make
> one request to a server to create and validate a certification path given an
> end-entity certificate, with the option of having the server return the path
> in its response. It should also be possible to include one or more
> end-entity certificates in a request.
If this requirement would be the only one, wouldn't be a conformant
implementation just be a sequence of certificates sent
within connection to an authenticatable server, and get a sequence of
chains back?
Other "possible" requirements or questions:
- The result of the service should not only be verifiable at the
moment when received by the client, but also later.
- If multiple certs are validated, should it be
possible to split the result, and keeping the possiblity of
authenticating the response parts, or not.
- Is a response independant of the request, or is it necessary
to include a reference to it in the longterm authenticable
part.
- The server indicates why the certification path is valid and what
efforts have been made.
- The response may be included in some data (for example as
part of a signed attribute).
- The service should help to verify a xmldsig signature. I.e., the
result should allow a thin client to present a human readable
interpretation of the certificate and the verified path without
looking at the asn1 blobs.
- ...
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15778 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 09:01:09 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <4K5TVNAP>; Fri, 10 Nov 2000 12:00:18 -0500
Message-ID: <DD62792EA182FF4E99C2FBC07E3053BD053E78@sottmxs09.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: "'Russ Housley'" <housley@spyrus.com>
Cc: ietf-pkix@imc.org
Subject: RE: OCSP-X vs SCVP
Date: Fri, 10 Nov 2000 12:07:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04B38.BE114AF0"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C04B38.BE114AF0
Content-Type: text/plain;
charset="iso-8859-1"
Hi Russ,
> ----------
> From: Russ Housley[SMTP:housley@spyrus.com]
> Sent: Thursday, November 09, 2000 5:11 PM
> To: ietf-pkix@imc.org
> Subject: OCSP-X vs SCVP
>
> A few weeks ago, there was a brief discussion of OCSP-X vs SCVP. The only
>
> consensus point was that we need to have one PKIX solution for
> certification path validation, not two. However, we did not pick one of
> these two alternatives. I think we need to pick one. We should not put
> further efforts into two solutions.
I think we're all in agreement here (including the chairs). My
understanding is that by the end of this year (perhaps at the San Diego PKIX
meeting, or perhaps immediately afterward via straw poll on the list) the
PKIX group will have chosen a single protocol into which to put its efforts.
> There are at least three communities that need to be served by this
> protocol: very lightweight clients, organizations that want centralized
> control, and clients that do not parse ASN.1 but understand XML. I am not
>
> sure that there is consensus about these user groups. If not, we need to
> get to consensus ...
I don't know if there is consensus about these three groups either, but they
sound reasonable to me.
> If these are the user groups that we are trying to satisfy, then I think
> that SCVP is the better answer.
Here is where your train of thought loses me.
- Is SCVP significantly lighter weight than OCSP with the validation
extension? I think it may possibly be lighter, but it's not clear to me
that there is a significant difference, so I see little distinction here on
which to make a decision.
- Organizations that want centralized control -- and want to achieve this
through the use of a central server that gives validation answers -- can
equally use SCVP or OCSP/DPV. The central responder model is the basis of
both protocols, so again I don't see a distinction here.
- The value of XML (versus ASN.1 DER) for delegated path validation or
discovery can be debated long and hard, and probably will be :-) However,
these are just alternate encodings for the information that travels over the
wire between the requester and the responder. Either protocol can be
encoded in either way (as illustrated by SCVP, which is encoded in both
ASN.1 DER and XML in the spec.). OCSP and its extensions does not currently
have an appendix saying how to encode the protocol in XML, but there is
nothing preventing a competent XML devotee from spending an hour to write
this up and give it to the editors for inclusion. So, the XML "argument"
does not distinguish these protocols either.
> Let the debate begin ...
Agreed. Let the debate begin, but let it be based on something that will
allow us to come to a conclusion. To me, the real distinguishing feature
between the two offerings is fairly straightforward: does it make sense for
the PKIX Working Group to define a framework for the "responder model"
within which various questions can be asked in a standardized manner? If
so, then OCSP is the right answer. (It currently proposes three possible
questions: what is the status? what is the validity with respect to a given
purpose? and what is the path with respect to a given root? Other questions
can be defined if and when needed.) If we don't want such a framework, then
we should go the other route and define a brand new protocol for every new
question that someone dreams up.
I personally see little value in the latter alternative, regardless of how
much fun it is to create new protocols. It makes much more sense to support
such related questions in a framework protocol, especially because there may
be cases in which combinations of questions are of interest to the requester
(e.g., "give me the status (or the validation) answer, but ALSO give me the
path you found so I can keep it for my evidence/archive records").
I think the framework protocol for the responder model is the right approach
for defining and posing a set of similar questions. I suspect that as time
moves on and we see requirements for new questions (or nuances on existing
questions), having such a framework will stand us in good stead. This is
why I've come down on the OCSP side, even though I currently see nothing
technically wrong with SCVP. If XML is important (and I know that it is
perceived to be, for at least some environments), then I'm sure that someone
can find a co-op somewhere who'll do an encoding for OCSP and its extensions
faster than America can choose a new President... :-)
Carlisle.
------_=_NextPart_001_01C04B38.BE114AF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: OCSP-X vs SCVP</TITLE>
</HEAD>
<BODY>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Russ,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Russ =
Housley[SMTP:housley@spyrus.com]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Thursday, November 09, 2000 5:11 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">ietf-pkix@imc.org</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">OCSP-X vs SCVP</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">A few weeks ago, there was a brief =
discussion of OCSP-X vs SCVP. The only </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">consensus point was that we need to =
have one PKIX solution for </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certification path validation, not =
two. However, we did not pick one of </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">these two alternatives. I think =
we need to pick one. We should not put </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">further efforts into two =
solutions.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman"> </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I think =
we're all in agreement here (including the chairs). My =
understanding is that by the end of this year (perhaps at the San Diego =
PKIX meeting, or perhaps immediately afterward via straw poll on the =
list) the PKIX group will have chosen a single protocol into which to =
put its efforts.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">There are at least three communities =
that need to be served by this </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">protocol: very lightweight clients, =
organizations that want centralized </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">control, and clients that do not =
parse ASN.1 but understand XML. I am not </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sure that there is consensus about =
these user groups. If not, we need to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">get to consensus ...</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman"> </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I don't =
know if there is consensus about these three groups either, but they =
sound reasonable to me.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">If these are the user groups that we =
are trying to satisfy, then I think </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that SCVP is the better =
answer.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman"> </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Here is =
where your train of thought loses me. </FONT>
</P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman"> - Is =
SCVP significantly lighter weight than OCSP with the validation =
extension? I think it may possibly be lighter, but it's not clear =
to me that there is a significant difference, so I see little =
distinction here on which to make a decision.</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman"> - =
Organizations that want centralized control -- and want to achieve this =
through the use of a central server that gives validation answers -- =
can equally use SCVP or OCSP/DPV. The central responder model is =
the basis of both protocols, so again I don't see a distinction =
here.</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman"> - =
The value of XML (versus ASN.1 DER) for delegated path validation or =
discovery can be debated long and hard, and probably will be =
:-) However, these are just alternate encodings for the =
information that travels over the wire between the requester and the =
responder. Either protocol can be encoded in either way (as =
illustrated by SCVP, which is encoded in both ASN.1 DER and XML in the =
spec.). OCSP and its extensions does not currently have an =
appendix saying how to encode the protocol in XML, but there is nothing =
preventing a competent XML devotee from spending an hour to write this =
up and give it to the editors for inclusion. So, the XML =
"argument" does not distinguish these protocols =
either.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Let the debate begin ...</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman"> </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Agreed. Let the debate begin, but let it be based on =
something that will allow us to come to a conclusion. To me, the =
real distinguishing feature between the two offerings is fairly =
straightforward: does it make sense for the PKIX Working Group to =
define a framework for the "responder model" within which =
various questions can be asked in a standardized manner? If so, =
then OCSP is the right answer. (It currently proposes three =
possible questions: what is the status? what is the validity with =
respect to a given purpose? and what is the path with respect to a =
given root? Other questions can be defined if and when =
needed.) If we don't want such a framework, then we should go the =
other route and define a brand new protocol for every new question that =
someone dreams up.</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I =
personally see little value in the latter alternative, regardless of =
how much fun it is to create new protocols. It makes much more =
sense to support such related questions in a framework protocol, =
especially because there may be cases in which combinations of =
questions are of interest to the requester (e.g., "give me the =
status (or the validation) answer, but ALSO give me the path you found =
so I can keep it for my evidence/archive records").</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I think =
the framework protocol for the responder model is the right approach =
for defining and posing a set of similar questions. I suspect =
that as time moves on and we see requirements for new questions (or =
nuances on existing questions), having such a framework will stand us =
in good stead. This is why I've come down on the OCSP side, even =
though I currently see nothing technically wrong with SCVP. If =
XML is important (and I know that it is perceived to be, for at least =
some environments), then I'm sure that someone can find a co-op =
somewhere who'll do an encoding for OCSP and its extensions faster than =
America can choose a new President... :-)</FONT></P>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C04B38.BE114AF0--
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12828 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 08:31:15 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA36990; Fri, 10 Nov 2000 11:37:16 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id LAA83804; Fri, 10 Nov 2000 11:36:40 -0500
Importance: Normal
Subject: Re: Extended Key Usage and CP extensions (path validation)
To: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Cc: ietf-pkix <ietf-pkix@imc.org>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF91FC1220.48F8AFDF-ON85256993.005A072E@somers.hqregion.ibm.com>
From: "Tom Gindin/Watson/IBM" <tgindin@us.ibm.com>
Date: Fri, 10 Nov 2000 11:37:36 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.5 |September 22, 2000) at 11/10/2000 11:37:49 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
IMHO the CP extension is not a good place for this, since the set of
policy OID's is not standardized and the OID's are not related to those for
EKU. That leaves us with three basic possibilities, since EKU with its
normal meaning is not very useful in CA certificates:
1 Define EKU as having its current meaning when it appears in an EE
certificate, and as a constraint when it appears in a CA certificate.
Thus, if an EE certificate is issued by a CA certificate with an EKU
extension, it may not have any EKU value not included in the CA
certificate's EKU extension. This matches your suggestion.
2 Deprecate EKU in CA certificates, and define an EKU constraint
extension. Either this would be a SET OF (or SEQUENCE OF) OID's, with the
same meaning as in case 1, or it would be defined as a CHOICE between
included and excluded, with included being a SET or SEQUENCE of OID's with
the same meaning as in case 1 and excluded being a SET or SEQUENCE of OID's
which may not appear in the EKU of any EE certificate descended from this
one.
3 Deprecate EKU in CA certificates, and declare that the function is not
really needed. One argument in favor of this is that there is no way to
constrain a CA from issuing a certificate with most of the KeyUsage flags
either, and NR is as strong a case for delegation constraint as most
currently assigned EKU values.
Tom Gindin
Jean-Marc Desperrier <jean-marc.desperrier@certplus.com> on 11/10/2000
05:01:06 AM
To: ietf-pkix <ietf-pkix@imc.org>
cc:
Subject: Re: Extended Key Usage and CP extensions (path validation)
"David P. Kemp" wrote:
> I'm not convinced that EKU serves a useful purpose. And if EKU itself
> is useful, I'm even less convinced that constraining it at the CA
> level, whatever the mechanism, is useful. If you want EKUs, and you
> don't trust a CA to issue EE certs with proper EKUs, then you shouldn't
> accept the CA.
They are grayer area than that.
If it were that true, there would be no need for basic constraints, name
constraints,
and policy constraints either.
> But if there is a need to use EKU, and to limit it by
> CA, then that need should be satisfied with a clean mechanism, not by
> bastardizing the CP extension.
Well, I'm not sure either that EKU serves an useful purpose in a CA
certificate.
We know it's going to be only used to sign certificates, so do we ever
actually need an
EKU for a CA, as is described in the current rfc2459 wording ?
It's different for the EE : For example putting a time-stamping extension
in the EKU is
mandatory in the TSP draft.
I think every CA certificate currently in use that include a EKU extension,
does it with
the intend that it will be interpreted according to the Netscape/Microsoft
misusage, not
the official rfc2459 usage.
If I can be proven otherwise, it invalidates the rest of this message, so
please provide
information about this.
I've been reading the discussion about the CP.
As has been said already
"A rule of thumb might that KU/EKU specifies things which could be be
wired into a generic toolkit, but CP specifies things which must be
decided by application-specific code."
Therefore I have the following suggestion :
I wonder if would not be a nice idea to treat the EKU in a way that's more
similar to
the CP extension.
Something like :
In an end-entity certificate, these extended key usages indicate ...
In a CA certificate, these extended key usage limit the set of extended key
usage for
certification paths which include this certificate.
I think this would be simpler that creating a new extension and since this
is already
the mecanims for the CP extension, I don't see the problem in applying it
to the EKU
extension too, especially since this the way the market already treats the
EKU
extension.
Any other solution will be very hard to get accepted by the market, and
will probably
lead to a situation where the rfc says one thing, and the market does
another, or at
least to a very long transition period, so if there's a way to avoid that,
just why not
?
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11202 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 07:52:13 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28502 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 07:59:13 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA22401 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 10:59:04 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA16294 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 10:59:03 -0500 (EST)
Message-ID: <3A0C1AC7.3CC33789@sun.com>
Date: Fri, 10 Nov 2000 10:56:55 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: Holder
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Well, my list of scenarios does not seem to be helping us resolve this
issue.
I will make a specific proposal, seeking comments or consensus. Since
none of the scenarios demonstrates a need for hints in Holder formats
that include the objectDigestInfo component, I propose that we adopt the
following recommendation, which would be incorporated into the next
version of ac509 (along with text explaining the various formats, how
they must be handled for validation purposes, and why each one might be
preferred to the others).
AC issuers SHOULD use only formats 2, 4, or 5. They MAY use other
formats, as necessary. AC verifiers SHOULD support formats 2, 4, and
5 (subject to specific requirements and configuration). They MAY
support other formats.
I welcome comments from others on this proposal. A good argument can be
made for replacing format 5 with format 9, if only for debugging
purposes. But I'd rather not recommend support for both, if possible.
-Steve
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04127 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 06:58:21 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G3T00C01DX12Z@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 10 Nov 2000 07:05:25 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G3T00BCXDX15M@ext-mail.valicert.com>; Fri, 10 Nov 2000 07:05:25 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <WS7NLD27>; Fri, 10 Nov 2000 07:03:34 -0800
Content-return: allowed
Date: Fri, 10 Nov 2000 07:03:25 -0800
From: Frank Balluffi <frankb@valicert.com>
Subject: RE: OCSP-X vs SCVP
To: "'Peter Sylvester'" <Peter.Sylvester@EdelWeb.fr>, ietf-pkix@imc.org
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E1365E8@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
It seems to me that this discussion has focused on encoding and syntax, but
not on the semantics of path creation and validation. In other words, what
are the requirements for server-based (including delegated) path creation
(or discovery) and validation.
I would like to see PKIX's solution support the ability for a client to make
one request to a server to create and validate a certification path given an
end-entity certificate, with the option of having the server return the path
in its response. It should also be possible to include one or more
end-entity certificates in a request.
Frank
> -----Original Message-----
> From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr]
> Sent: Friday, November 10, 2000 8:29 AM
> To: ietf-pkix@imc.org
> Subject: Re: OCSP-X vs SCVP
>
>
> >
> > A few weeks ago, there was a brief discussion of OCSP-X vs
> SCVP. The only
> > consensus point was that we need to have one PKIX solution for
> > certification path validation, not two. However, we did
> not pick one of
> > these two alternatives. I think we need to pick one. We
> should not put
> > further efforts into two solutions.
>
> >
> > There are at least three communities that need to be served by this
> > protocol: very lightweight clients, organizations that want
> centralized
> > control, and clients that do not parse ASN.1 but understand
> XML. I am not
> > sure that there is consensus about these user groups. If
> not, we need to
> > get to consensus ...
>
> >
> > If these are the user groups that we are trying to satisfy,
> then I think
> > that SCVP is the better answer.
> >
> > Let the debate begin ...
>
> If I remember correctly, the first element of the discussion was
> that we are actually talking about 'two services', i.e., path
> determintation and path validation. And that there was some feeling
> that the SCVP definition of path determination is not sufficient.
>
> Or, SCVP contains two completely different parts, and at least
> one of them is not a protocol at all.
>
> Furthermore, I do not think that having defined two concrete encoding
> for the same abstract data is enough reason alone to choose a
> protocol.
>
> The ASN1 SCVP encoding use 'yet another signature scheme'.
> It is already unfortunate that in the ASN1 case we have at least three
> different ways of signing data, i.e., x509 certs, pkcs7 signeddata,
> ocsp responses. I don't think we need a new one. Think about the
> the code to validate a time stamped pkcs7 extended signature
> containing some responses from ocps and maybe scvp.
>
> The error and status codes defined a character strings are not reusing
> semantically equivalent and already existing data like PKIStatus.
>
> The XML part still requires that an implementation knows
> something about
> ASN1. What about having the protocol not just validate the
> certificate,
> but also to extract the textual components like
> X509IssuerSerial, keyInfo
> etc, i.e. allow a very light client that has no ASN1
> knowledge at all.
>
> The overall OCSP response data structures are also somewhat
> unfortunate.
> There are several layers: an unsigned outer part, a security envelope
> (signature), signing arbitary content defined by an OID.
> Several content
> definition. IMHO, the outer level is useless, because you
> need to look at
> the signed content anyway. The signature scheme is as bad as
> the X509 cert
> scheme, two passes necessary for verification. I am not quite
> sure why one
> hadn't simply used pkcs7.
>
> I have the impression that any of the content types that are defined
> in OCSP, or TSP, etc, could be encoded as well in XER++
> instead of DER,
> CER, BER. IMHO this encoding rules should not be defined on a protocol
> by protocol basis, but in a general way. This may needs some
> restriction
> of the use of some ASN1 features or/and a way to express
> things like asn1
> structures encapsulated in octet/bitstrings, in order to get
> a non blob
> version of Extensions for example.
>
> Then, for example If someone likes the PSResponse content, it
> seems possible
> to me to define an OID for that and use this either in an
> OCSP response, or
> as a pkcs7 signed data content, or as xmldsig protected data.
> In other words, any protocol should specify the data to be
> transported,
> requirement about the security needs for transport and long
> term, and one
> should try to use already established techniques.
>
> BTW: Marc is right about ASN1: "liberez A S N un, liberez A S
> N un" !!! :-)
>
> nuf said.
> Peter
>
Received: from edelweb.fr ([212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27598 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 05:21:40 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA02226 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 14:28:44 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 10 Nov 2000 14:28:44 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA13330 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 14:28:42 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA00878 for ietf-pkix@imc.org; Fri, 10 Nov 2000 14:28:41 +0100 (MET)
Date: Fri, 10 Nov 2000 14:28:41 +0100 (MET)
Message-Id: <200011101328.OAA00878@emeriau.edelweb.fr>
To: ietf-pkix@imc.org
Subject: Re: OCSP-X vs SCVP
>
> A few weeks ago, there was a brief discussion of OCSP-X vs SCVP. The only
> consensus point was that we need to have one PKIX solution for
> certification path validation, not two. However, we did not pick one of
> these two alternatives. I think we need to pick one. We should not put
> further efforts into two solutions.
>
> There are at least three communities that need to be served by this
> protocol: very lightweight clients, organizations that want centralized
> control, and clients that do not parse ASN.1 but understand XML. I am not
> sure that there is consensus about these user groups. If not, we need to
> get to consensus ...
>
> If these are the user groups that we are trying to satisfy, then I think
> that SCVP is the better answer.
>
> Let the debate begin ...
If I remember correctly, the first element of the discussion was
that we are actually talking about 'two services', i.e., path
determintation and path validation. And that there was some feeling
that the SCVP definition of path determination is not sufficient.
Or, SCVP contains two completely different parts, and at least
one of them is not a protocol at all.
Furthermore, I do not think that having defined two concrete encoding
for the same abstract data is enough reason alone to choose a protocol.
The ASN1 SCVP encoding use 'yet another signature scheme'.
It is already unfortunate that in the ASN1 case we have at least three
different ways of signing data, i.e., x509 certs, pkcs7 signeddata,
ocsp responses. I don't think we need a new one. Think about the
the code to validate a time stamped pkcs7 extended signature
containing some responses from ocps and maybe scvp.
The error and status codes defined a character strings are not reusing
semantically equivalent and already existing data like PKIStatus.
The XML part still requires that an implementation knows something about
ASN1. What about having the protocol not just validate the certificate,
but also to extract the textual components like X509IssuerSerial, keyInfo
etc, i.e. allow a very light client that has no ASN1 knowledge at all.
The overall OCSP response data structures are also somewhat unfortunate.
There are several layers: an unsigned outer part, a security envelope
(signature), signing arbitary content defined by an OID. Several content
definition. IMHO, the outer level is useless, because you need to look at
the signed content anyway. The signature scheme is as bad as the X509 cert
scheme, two passes necessary for verification. I am not quite sure why one
hadn't simply used pkcs7.
I have the impression that any of the content types that are defined
in OCSP, or TSP, etc, could be encoded as well in XER++ instead of DER,
CER, BER. IMHO this encoding rules should not be defined on a protocol
by protocol basis, but in a general way. This may needs some restriction
of the use of some ASN1 features or/and a way to express things like asn1
structures encapsulated in octet/bitstrings, in order to get a non blob
version of Extensions for example.
Then, for example If someone likes the PSResponse content, it seems possible
to me to define an OID for that and use this either in an OCSP response, or
as a pkcs7 signed data content, or as xmldsig protected data.
In other words, any protocol should specify the data to be transported,
requirement about the security needs for transport and long term, and one
should try to use already established techniques.
BTW: Marc is right about ASN1: "liberez A S N un, liberez A S N un" !!! :-)
nuf said.
Peter
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA13470 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 01:55:04 -0800 (PST)
Received: from certplus.com ([192.168.212.171]) by certplus.com (8.8.7/8.8.7) with ESMTP id LAA22371 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 11:07:14 +0100
Message-ID: <3A0BC762.57CC75A9@certplus.com>
Date: Fri, 10 Nov 2000 11:01:06 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Extended Key Usage and CP extensions (path validation)
References: <200011091639.LAA13549@roadblock.missi.ncsc.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"David P. Kemp" wrote:
> I'm not convinced that EKU serves a useful purpose. And if EKU itself
> is useful, I'm even less convinced that constraining it at the CA
> level, whatever the mechanism, is useful. If you want EKUs, and you
> don't trust a CA to issue EE certs with proper EKUs, then you shouldn't
> accept the CA.
They are grayer area than that.
If it were that true, there would be no need for basic constraints, name constraints,
and policy constraints either.
> But if there is a need to use EKU, and to limit it by
> CA, then that need should be satisfied with a clean mechanism, not by
> bastardizing the CP extension.
Well, I'm not sure either that EKU serves an useful purpose in a CA certificate.
We know it's going to be only used to sign certificates, so do we ever actually need an
EKU for a CA, as is described in the current rfc2459 wording ?
It's different for the EE : For example putting a time-stamping extension in the EKU is
mandatory in the TSP draft.
I think every CA certificate currently in use that include a EKU extension, does it with
the intend that it will be interpreted according to the Netscape/Microsoft misusage, not
the official rfc2459 usage.
If I can be proven otherwise, it invalidates the rest of this message, so please provide
information about this.
I've been reading the discussion about the CP.
As has been said already
"A rule of thumb might that KU/EKU specifies things which could be be
wired into a generic toolkit, but CP specifies things which must be
decided by application-specific code."
Therefore I have the following suggestion :
I wonder if would not be a nice idea to treat the EKU in a way that's more similar to
the CP extension.
Something like :
In an end-entity certificate, these extended key usages indicate ...
In a CA certificate, these extended key usage limit the set of extended key usage for
certification paths which include this certificate.
I think this would be simpler that creating a new extension and since this is already
the mecanims for the CP extension, I don't see the problem in applying it to the EKU
extension too, especially since this the way the market already treats the EKU
extension.
Any other solution will be very hard to get accepted by the market, and will probably
lead to a situation where the rfc says one thing, and the market does another, or at
least to a very long transition period, so if there's a way to avoid that, just why not
?
Received: from caronte.gmv.es (firewall-user@caronte.gmv.es [195.235.177.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA11353 for <ietf-pkix@imc.org>; Fri, 10 Nov 2000 01:36:03 -0800 (PST)
Received: by caronte.gmv.es; id KAA16049; Fri, 10 Nov 2000 10:43:03 +0100
Received: from unknown(192.168.18.16) by caronte.gmv.es via smap (V5.5) id xmab15915; Fri, 10 Nov 00 10:42:47 +0100
Received: from pcrrln (pcrrln.esegi.es [192.168.18.148]) by esegi.es (8.9.1b+Sun/8.9.1) with SMTP id KAA15582; Fri, 10 Nov 2000 10:43:39 +0100 (MET)
From: "Roberto Lopez Navarro" <rolopez@sgi.es>
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>, <ietf-pkix@imc.org>
Subject: RE: Extended Key Usage and path validation
Date: Fri, 10 Nov 2000 10:47:38 +0100
Message-ID: <HMEAJGDPDOCIEHBCFGAEIEMPCHAA.rolopez@sgi.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200011091639.LAA13549@roadblock.missi.ncsc.mil>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
>I agree with Patrick Patterson and Michael Ströder that using the
>Certificate Policies extension to control usage of the EE key
>"messes with" the CP extension.
I am agree with you. I do not think it is the proper extension. Certificate
Policies extension has a role on path validation and trust management, but
given that there is no standarization of Certificate Policies, it will be
hard if not impssible to use it for key usage management.
>The policy under which certificates
>are issued seems tenuously related, if not completely unrelated,
>to the applications which make use of the certificates.
I always thought that the certificate policy under which a certificate is
issued is closely related with the applications that make use of them.
Certificate policy - A named set of rules that indicates the
applicability of a certificate to a particular community and/or
class of application with common security requirements. For
example, a particular certificate policy might indicate
applicability of a type of certificate to the authentication of
electronic data interchange transactions for the trading of goods
within a given price range.
What's the important word of this definition? Applicability as for
nonrepudiation, digitalsignature, etc? Or class of application, like TLS
authetication, S/MIME confidentiality, etc? I think both of them.
I really think that EKU is an important extension, because you can profile
different policies for applications. For example, a TLS certificate and
S/MIME certificate could have the same KU extensions but a different EKU
ones. Or the other way round, you could have to S/MIME certificates, one for
signing (KU digitalSignature) and one for confidentiality (KU
keyEncipherment). The EKU will reflect the statements made in the CP, for
the heck of automatization. Maybe, it will be useful to define EKU
appropiate for CA certificates (as Netscape did with Netscape Cert Type
extension).
But,as always, I am not quite sure about it.
Best regards
Roberto
===========================================
Roberto Lopez Navarro
[mailto:rolopez@sgi.es]
tfno: +34 91 806 46 40
fax: +34 91 806 46 41
SGI Soluciones Globales Internet
[http://www.sgi.es]
GMV Sistemas S.A.
============================================
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA27602 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 23:53:51 -0800 (PST)
Received: from mega (t3o69p33.telia.com [62.20.145.33]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA06416; Fri, 10 Nov 2000 09:00:51 +0100 (CET)
Message-ID: <004a01c04aec$27b84960$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Khaja Ahmed" <Khaja.Ahmed@identrus.com>, <ietf-pkix@imc.org>
References: <A105E1C02F5DD31181A500508B5519EC3065AF@blue.identrus.com>
Subject: XML in PKIX. Was: OCSP-X vs SCVP
Date: Fri, 10 Nov 2000 08:59:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA27605
RE: OCSP-X vs SCVPKhaja,
<snip>
>The XML community I am referring to and am aware of is a group of financial institutions.
>(There may be others) These financial institutions have a group of application and solution
> developers within their ranks who (most of them) know and love XML. They prefer to avoid
>dealing with ASN.1. This XML community finds it easier to read, deal with and encode
>information in XML. They are able to debug protocol implementation problems where XML
>encoding is used. They know and are comfortable with XMLDSIG and use that rather than
>PKCS#7 to send signed transactions back and forth. They have plans to use delegated path
>validation so they will not be doing PKIX section 6.1 stuff locally. They want to increasingly move
>towards a set of protocols that use XML encoding for these reasons.
I would say that this statement is valid for the e-business sector in general.
According to some notable persons on this list, XML-encoded systems are not
the target for PKIX as it is based on ISO-standards which currently are ASN.1-based.
Steve K et al: Is'nt time to "adjust" the scope of PKIX and make the "X" not only refer
to "X"500 but to "X"ML?
<snip>
Regards
Anders
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10465; Thu, 9 Nov 2000 19:00:11 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id NAA19478; Fri, 10 Nov 2000 13:14:49 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <WRV4VNSP>; Fri, 10 Nov 2000 14:05:46 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCACF90CD@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Paul Hoffman / IMC <phoffman@imc.org>, Michael Zolotarev <mzolotarev@baltimore.com>, Marc Branchaud <marcnarc@xcert.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Fri, 10 Nov 2000 14:05:45 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Paul,
I think this is a classic example of MZ been taken wrong once again,
unfortunately.
And it was the least of my intentions to be "loud and repetitive".
The point I'm trying to make is that we have to be really careful about
rushing into XML.
In many cases - and I'm sure you'll be able to confirm it more than anybody
else - people say XML, and want XML, and 'can' XML just for heck of it.
Trying to push XML into places where it doesn't really belong, or have no
technical reasons to be.
The line between protocols and APIs is a subtle one. There is a common mixup
between what is protocol, and what is the presentation layer. The use of
OCSP by XML-enabled applications can be, and should be IMHO facilitated by
APIs. With the application been completely unaware of what goes through the
wire, and what is the format of what was transmitted.
And so far I didn't hear any single argument which justifies (except just
saying 'our customers want it') the opposite. Still waiting...
Again, I'm not against XML in PKI. And I can be as loud and repetitive as I
am defending use of XML in other areas of PKI. But with OCSP - sorry, I'm
not convinced.
Michael
> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:phoffman@imc.org]
> Sent: Friday, 10 November 2000 12:03
> To: Michael Zolotarev; Marc Branchaud
> Cc: 'ietf-pkix@imc.org '
> Subject: RE: OCSP-X vs SCVP
>
>
> At 12:06 PM +1100 11/10/00, Michael Zolotarev wrote:
> > >
> >> > > But that ain't how the world works, and
> >> > > that ain't how
> >> > > people want it to work.
> >> >
> >> > Proof, please. I want the proof.
> >> >
> >>
> >> The fact that people seem to care about this is proof
> enough for me...
> >
> >MArk, this is really speculative thing to say... I don't buy it as an
> >argument, sorry.
>
> It is not speculative. There have been people on this mailing list
> who have said that they want an XML-based solution. Telling them that
> you don't buy their opinion as an argument will tend to cause them
> not to contribute again, yes? At that point, the WG will reduce to
> those of us who are loud and repetitive. That is not a good way to
> produce good protocols.
>
> >Dont think it is a real issue with hosts and desktops. Dont
> think there is
> >an issue with mobile devices either. I am not saying it is a
> bloat, or it is
> >not. I just want some approx figures. Compare bare-minimum
> >ASNParser+OCSP_APIs with OCSP_XML_APIs ( for fairness I
> assume that XML
> >parser is present on the platform regardless, so it doesn't count).
>
> This level of argument reduces to "the customer is usually wrong".
> That works in some areas, not in others. Given two protocols that
> could meet the same objectives, such arguments are likely to squelch
> input from the very people we should be listening to.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09312; Thu, 9 Nov 2000 17:56:27 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05010443b63106d22030@[165.227.249.17]>
In-Reply-To: <D44EACB40164D311BEF00090274EDCCACF8F95@sydneymail1.jp.zergo.com.au>
References: <D44EACB40164D311BEF00090274EDCCACF8F95@sydneymail1.jp.zergo.com.au>
Date: Thu, 9 Nov 2000 18:03:29 -0800
To: Michael Zolotarev <mzolotarev@baltimore.com>, Marc Branchaud <marcnarc@xcert.com>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: RE: OCSP-X vs SCVP
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 12:06 PM +1100 11/10/00, Michael Zolotarev wrote:
> >
>> > > But that ain't how the world works, and
>> > > that ain't how
>> > > people want it to work.
>> >
>> > Proof, please. I want the proof.
>> >
>>
>> The fact that people seem to care about this is proof enough for me...
>
>MArk, this is really speculative thing to say... I don't buy it as an
>argument, sorry.
It is not speculative. There have been people on this mailing list
who have said that they want an XML-based solution. Telling them that
you don't buy their opinion as an argument will tend to cause them
not to contribute again, yes? At that point, the WG will reduce to
those of us who are loud and repetitive. That is not a good way to
produce good protocols.
>Dont think it is a real issue with hosts and desktops. Dont think there is
>an issue with mobile devices either. I am not saying it is a bloat, or it is
>not. I just want some approx figures. Compare bare-minimum
>ASNParser+OCSP_APIs with OCSP_XML_APIs ( for fairness I assume that XML
>parser is present on the platform regardless, so it doesn't count).
This level of argument reduces to "the customer is usually wrong".
That works in some areas, not in others. Given two protocols that
could meet the same objectives, such arguments are likely to squelch
input from the very people we should be listening to.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA08748 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 17:38:11 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 07441942; Thu, 9 Nov 2000 20:38:03 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-81-199.bellatlantic.net [141.154.81.199]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id UAA07499; Thu, 9 Nov 2000 20:43:54 -0500
Message-ID: <3A0B51F7.43500AAA@caveosystems.com>
Date: Thu, 09 Nov 2000 20:40:07 -0500
From: Rich Salz <rsalz@caveosystems.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'Russ Housley '" <housley@spyrus.com>
CC: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: OCSP-X vs SCVP
References: <D44EACB40164D311BEF00090274EDCCACF8E98@sydneymail1.jp.zergo.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
I think that we should wait, let vendors (and communities) get some experience
deploying solutions, and see what shakes out. There are certainly risks, but
I think it imprudent to create something from scratch. By waiting, we at
least get to see which community(ies) form, and what needs must be addressed.
Until that happens, it's just like guess hypothetical dot-com marketshare. :)
/r$
Received: from home.x509.com (home.x509.com [199.175.150.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08412 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 17:24:54 -0800 (PST)
Received: from xcert.com (trinity.x509.com [199.175.148.59]) by home.x509.com (8.11.0/XCERT) with ESMTP id eAA1Vui41496 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 17:31:56 -0800 (PST)
Sender: marcnarc@xcert.com
Message-ID: <3A0B4F99.F061C550@xcert.com>
Date: Thu, 09 Nov 2000 17:30:01 -0800
From: Marc Branchaud <marcnarc@xcert.com>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: OCSP-X vs SCVP
References: <D44EACB40164D311BEF00090274EDCCACF8F95@sydneymail1.jp.zergo.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
OK, this is going nowhere, and I don't care enough about it to continue. I'd
really like to see this thread get onto deciding between the two protocols,
so I'll shut up.
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marcnarc@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
Michael Zolotarev wrote:
>
> >
> > > > But that ain't how the world works, and
> > > > that ain't how
> > > > people want it to work.
> > >
> > > Proof, please. I want the proof.
> > >
> >
> > The fact that people seem to care about this is proof enough for me...
>
> MArk, this is really speculative thing to say... I don't buy it as an
> argument, sorry.
> >
> >
> > But I see your point. You weren't talking about an OCSP API,
> > but instead an
> > ASN.1 (as opposed to XML) API.
>
> No, I was talking exactly about OCSP APIs. pki_GetOCSP(). I didn;t meant
> using ASN1 directly by the applications. That't be a very much wrong thing
> to do.
>
> At that level, I agree:
> > people can pick up
> > toolkits to work with either.
>
> > The non-PKI folk want their
> > XML apps to use
> > PKI (as do the PKI folks, I might add), but they don't want
> > to bloat their
> > apps with an ASN.1 toolkit. Similarly, the PKI folk don't
> > want to bloat
> > their apps with an XML toolkit.
> >
> Bloat? got any real figures?
>
> Dont think it is a real issue with hosts and desktops. Dont think there is
> an issue with mobile devices either. I am not saying it is a bloat, or it is
> not. I just want some approx figures. Compare bare-minimum
> ASNParser+OCSP_APIs with OCSP_XML_APIs ( for fairness I assume that XML
> parser is present on the platform regardless, so it doesn't count).
>
> > Either some non-PKI folk have to want PKI badly enough to
> > accept the bloat,
> > or the PKI folk have to want to spread PKI badly enough to
> > adopt XML. Either
> > way, someone has to give.
> >
> > Marc
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08002 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 17:01:26 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA17762; Fri, 10 Nov 2000 11:15:58 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <WRV4VN3S>; Fri, 10 Nov 2000 12:06:55 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCACF8F95@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Marc Branchaud <marcnarc@xcert.com>, Michael Zolotarev <mzolotarev@baltimore.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Fri, 10 Nov 2000 12:06:54 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
>
> > > But that ain't how the world works, and
> > > that ain't how
> > > people want it to work.
> >
> > Proof, please. I want the proof.
> >
>
> The fact that people seem to care about this is proof enough for me...
MArk, this is really speculative thing to say... I don't buy it as an
argument, sorry.
>
>
> But I see your point. You weren't talking about an OCSP API,
> but instead an
> ASN.1 (as opposed to XML) API.
No, I was talking exactly about OCSP APIs. pki_GetOCSP(). I didn;t meant
using ASN1 directly by the applications. That't be a very much wrong thing
to do.
At that level, I agree:
> people can pick up
> toolkits to work with either.
> The non-PKI folk want their
> XML apps to use
> PKI (as do the PKI folks, I might add), but they don't want
> to bloat their
> apps with an ASN.1 toolkit. Similarly, the PKI folk don't
> want to bloat
> their apps with an XML toolkit.
>
Bloat? got any real figures?
Dont think it is a real issue with hosts and desktops. Dont think there is
an issue with mobile devices either. I am not saying it is a bloat, or it is
not. I just want some approx figures. Compare bare-minimum
ASNParser+OCSP_APIs with OCSP_XML_APIs ( for fairness I assume that XML
parser is present on the platform regardless, so it doesn't count).
> Either some non-PKI folk have to want PKI badly enough to
> accept the bloat,
> or the PKI folk have to want to spread PKI badly enough to
> adopt XML. Either
> way, someone has to give.
>
> Marc
>
> +-------------------------------------------------------------
> -----------+
> Marc Branchaud \/
> Chief PKI Architect /\CERT
> INTERNATIONAL INC.
> marcnarc@xcert.com PKI References page:
> www.xcert.com
> 604-640-6227 www.xcert.com/~marcnarc/PKI/
> +-------------------------------------------------------------
> -----------+
>
Received: from home.x509.com (home.x509.com [199.175.150.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07655 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 16:49:22 -0800 (PST)
Received: from xcert.com (trinity.x509.com [199.175.148.59]) by home.x509.com (8.11.0/XCERT) with ESMTP id eAA0uFi41295; Thu, 9 Nov 2000 16:56:15 -0800 (PST)
Sender: marcnarc@xcert.com
Message-ID: <3A0B473B.A67F994@xcert.com>
Date: Thu, 09 Nov 2000 16:54:19 -0800
From: Marc Branchaud <marcnarc@xcert.com>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: Michael Zolotarev <mzolotarev@baltimore.com>
CC: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: OCSP-X vs SCVP
References: <D44EACB40164D311BEF00090274EDCCACF8F59@sydneymail1.jp.zergo.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael Zolotarev wrote:
>
> > But that ain't how the world works, and
> > that ain't how
> > people want it to work.
>
> Proof, please. I want the proof.
>
The fact that people seem to care about this is proof enough for me...
> As one of the vendors, I dare to claim that it absolutely does not matter
> for *a vendor* whether to deal with ASN1 or XML. There are other problems to
> tackle, much more serious, than specifics of the encoding. And every vendor
> has tools to handle encoding. There are tools for XML, and tools ASN. You
> want one - ask me. Nobody starts from scratch.
It seems to me that many *non-vendors* might want to implement the protocol.
But I see your point. You weren't talking about an OCSP API, but instead an
ASN.1 (as opposed to XML) API. At that level, I agree: people can pick up
toolkits to work with either.
Many, though, seem to be reluctant to have to work with both. I suppose
there this is where the crux of the issue lies. Most PKI folk work in ASN.1,
while many non-PKI folk use XML. The non-PKI folk want their XML apps to use
PKI (as do the PKI folks, I might add), but they don't want to bloat their
apps with an ASN.1 toolkit. Similarly, the PKI folk don't want to bloat
their apps with an XML toolkit.
Either some non-PKI folk have to want PKI badly enough to accept the bloat,
or the PKI folk have to want to spread PKI badly enough to adopt XML. Either
way, someone has to give.
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marcnarc@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07216 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 16:28:49 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA17341; Fri, 10 Nov 2000 10:43:13 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <WRV4VNNJ>; Fri, 10 Nov 2000 11:34:10 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCACF8F59@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Marc Branchaud <marcnarc@xcert.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Fri, 10 Nov 2000 11:34:10 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
> But that ain't how the world works, and
> that ain't how
> people want it to work.
Proof, please. I want the proof.
>
> Of course people will use APIs. But one way to judge the success of a
> protocol is by the number of toolkits that support it. I
> believe that it's
> important to design a protocol to be easy to implement, even
> if the vast
> majority of the protocol's users will never care.
>
As one of the vendors, I dare to claim that it absolutely does not matter
for *a vendor* whether to deal with ASN1 or XML. There are other problems to
tackle, much more serious, than specifics of the encoding. And every vendor
has tools to handle encoding. There are tools for XML, and tools ASN. You
want one - ask me. Nobody starts from scratch.
> (No flames, please! I'm quite happy with either standard.
> If I've one
> criticism, it's that the ASN.1 specs are not free.)
>
> Marc
>
> +-------------------------------------------------------------
> -----------+
> Marc Branchaud \/
> Chief PKI Architect /\CERT
> INTERNATIONAL INC.
> marcnarc@xcert.com PKI References page:
> www.xcert.com
> 604-640-6227 www.xcert.com/~marcnarc/PKI/
> +-------------------------------------------------------------
> -----------+
>
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06716 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 16:10:56 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA16866; Fri, 10 Nov 2000 10:25:22 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <WRV4VNMX>; Fri, 10 Nov 2000 11:16:19 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCACF8F3C@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Khaja Ahmed <Khaja.Ahmed@identrus.com>, Michael Zolotarev <mzolotarev@baltimore.com>, "''Russ Housley ' '" <housley@spyrus.com>, "''ietf-pkix@imc.org ' '" <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Fri, 10 Nov 2000 11:16:18 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04AAB.72A56980"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C04AAB.72A56980
Content-Type: text/plain;
charset="iso-8859-1"
Khaja,
Let me begin by saying that, from a purely objective perspective, a
reasonable to good case can be made for either approach. But it isn't about
what approach is technologically / demonstrably more efficient or in some
way better. It has more to do with what the target users of a protocol /
standard / solution want and can use.
Does Identrus use TLS? Do the target users 'want' use it? 'Can' they? Or
should we start of re-implementing TLS so that the TLS handshake protocol
exchanges XML messages from now on?
Would you agree it is quite absurd? Hope so.
We must realise that there is always a line between XML and 'everything
else'. Pushing that line down may be justified in one environment, and be
totally unprudent for others. The justifications would be the same as
always: what you want to see and what you don't, ease of use by the
end-apps, ease of implementing, ease of problem tracing, and I dare to say
efficiency (knowing it'll be never accepted as an argument by XML community
:).
Anyway, here is a deal: imagine that I can give you an OCSP responder which
implements both ASN and XML. Make your move, and give me a hypotetical but
realistic case of an XML system which will be using 'my' OCSP. Explain how
does your XML end-user application, or any other application in your system
WANT to use it. Also please explain how that very application CAN use it.
Show me where the reality of OCSP internal messaging and encoding gets
actually visible, and how doing it in XML way would make it more
appropriate.
And who knows - I may agree with you after all.
Best regards
Michael
That is what drives usage of technology. I do not claim to know what the
broad market wants. I just happen to know what a section (an important one)
leans towards.
The XML community I am referring to and am aware of is a group of financial
institutions. (There may be others) These financial institutions have a
group of application and solution developers within their ranks who (most of
them) know and love XML. They prefer to avoid dealing with ASN.1. This XML
community finds it easier to read, deal with and encode information in XML.
They are able to debug protocol implementation problems where XML encoding
is used. They know and are comfortable with XMLDSIG and use that rather than
PKCS#7 to send signed transactions back and forth. They have plans to use
delegated path validation so they will not be doing PKIX section 6.1 stuff
locally. They want to increasingly move towards a set of protocols that use
XML encoding for these reasons.
As you clearly and correctly point out their applications cannot really get
away completely from ASN.1 - at least yet. They are, therefore, willing and
able to use an API, which as you rightly observe, has to have ASN.1 parsing
capability to pop a key out of a certificate to verify a signature and do
sundry inescapable ASN.1 fiddling. What is however possible (and to the XML
community, desirable) is to increase the XML encoded content and decrease
the ASN.1 encoded content in their environments. I know of at least one
bank that has a team of engineers, which does everything XML in-house, and
need to get a fairly pricey contractor to deal with ASN.1 stuff. They are a
canonical representation of what I refer to as the "XML community".
I would suggest that it is reasonable to want to move along a continuum
towards increasing XML encoded content in one's space without getting all
the way there. Just because you can't completely escape ASN.1 is no reason
to continue to do everything in ASN.1.
Finally, (suspecting that this will come up) in the debate over how ASN.1 is
more compact and efficient relative to XML I would suggest we consider one
other aspect. In large scale use and deployment the number of people who
can deal with a given technology is a key factor. The fact that XML is more
human readable and easier to deal with is an efficiency factor that impacts
application availability.
Khaja
-----Original Message-----
From: Michael Zolotarev
To: Khaja Ahmed; 'Russ Housley '; 'ietf-pkix@imc.org '
Sent: 11/9/00 5:51 PM
Subject: RE: OCSP-X vs SCVP
Can anyone bother explaining a simple thing to me (I didn't have my
morning coffee yet, so I'm still mentally a bit retarded):
What is XML community, exactly? Is it a bunch of applications sitting on
top of XML-messaging backbone? Now then, do those application call any
APIs at all? Or do they do all the heavy-weight stuff themselves? I hope
that a concept of APIs is not totally abandoned in the "XML community".
Does anybody in the community create PKCS10 in hard way? Or parse a
certificate, or a CRL by doing it bit-by-bit, doesn;t matter what the
encoding is? I guess no. They use APIs.
If so ( if not, stop further reading), then obtaining OCSP is just
another matter for an API. And it absolutely doesn't matter if the API
uses ASN1 or XML or whatever else. The XML-community won't see it, and
must't see it. Exactly as it is for VB community, Fortran community,
Cobol community and IBM360 mcaro assembler community.
Time for my morning coffee. I'll be more bright when I'm back :) Please
response.
Michael
-----Original Message-----
From: Khaja Ahmed [ mailto:Khaja.Ahmed@identrus.com
<mailto:Khaja.Ahmed@identrus.com> ]
Sent: Friday, 10 November 2000 8:27
To: 'Russ Housley '; 'ietf-pkix@imc.org '
Subject: RE: OCSP-X vs SCVP
I would even go so far as to say that for the community that is XML
dependant the nomination you make is the only workable one.
Khaja
-----Original Message-----
From: Russ Housley
To: ietf-pkix@imc.org
Sent: 11/9/00 5:11 PM
Subject: OCSP-X vs SCVP
A few weeks ago, there was a brief discussion of OCSP-X vs SCVP. The
only
consensus point was that we need to have one PKIX solution for
certification path validation, not two. However, we did not pick one of
these two alternatives. I think we need to pick one. We should not put
further efforts into two solutions.
There are at least three communities that need to be served by this
protocol: very lightweight clients, organizations that want centralized
control, and clients that do not parse ASN.1 but understand XML. I am
not
sure that there is consensus about these user groups. If not, we need
to
get to consensus ...
If these are the user groups that we are trying to satisfy, then I think
that SCVP is the better answer.
Let the debate begin ...
Russ
------_=_NextPart_001_01C04AAB.72A56980
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: OCSP-X vs SCVP</TITLE>
<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=687140301-10112000><FONT face=Arial color=#0000ff
size=2>Khaja,</FONT></SPAN></DIV>
<DIV><SPAN class=687140301-10112000><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<P><FONT size=2>Let me begin by saying that, from a purely objective
perspective, a reasonable to good case can be made for either approach.
But it isn't about what approach is technologically / demonstrably more
efficient or in some way better. It has more to do with what the target users
of a protocol / standard / solution want and can use. <SPAN
class=687140301-10112000><FONT face=Arial
color=#0000ff> </FONT></SPAN></FONT></P></BLOCKQUOTE>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000>Does Identrus use TLS? Do the target users 'want' use
it? 'Can' they? Or should we start of re-implementing TLS so that the TLS
handshake protocol exchanges XML messages from now on?</SPAN></FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000>Would you agree it is quite absurd? Hope
so.</SPAN></FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000></SPAN></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000>We must realise that there is always a line between XML
and 'everything else'. Pushing that line down may be justified in one
environment, and be totally unprudent for others. The justifications would be
the same as always: what you want to see and what you don't, ease of use by the
end-apps, ease of implementing, ease of problem tracing, and I dare to say
efficiency (knowing it'll be never accepted as an argument by XML community
:).</SPAN></FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000></SPAN></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000>Anyway, here is a deal: imagine that I can give you an
OCSP responder which implements both ASN and XML. Make your move, and give me a
hypotetical but realistic case of an XML system which will be using 'my' OCSP.
Explain how does your XML end-user application, or any other application in
your system WANT to use it. Also please explain how that very application CAN
use it.</SPAN></FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000></SPAN></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000>Show me where the reality of OCSP internal messaging
and encoding gets actually visible, and how doing it in XML way would make
it more appropriate. </SPAN></FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000></SPAN></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000>And who knows - I may agree with you after
all.</SPAN></FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000></SPAN></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000>Best regards</SPAN></FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000>Michael</SPAN></FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000></SPAN></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2><SPAN
class=687140301-10112000></SPAN></FONT><FONT size=2><SPAN
class=687140301-10112000> </SPAN>That is what drives usage of
technology. I do not claim to know what the broad market wants. I just
happen to know what a section (an important one) leans towards.</FONT></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<P><FONT size=2>The XML community I am referring to and am aware of is a group
of financial institutions. (There may be others) These financial
institutions have a group of application and solution developers within their
ranks who (most of them) know and love XML. They prefer to avoid dealing
with ASN.1. This XML community finds it easier to read, deal with and
encode information in XML. They are able to debug protocol
implementation problems where XML encoding is used. They know and are
comfortable with XMLDSIG and use that rather than PKCS#7 to send signed
transactions back and forth. They have plans to use delegated path
validation so they will not be doing PKIX section 6.1 stuff locally.
They want to increasingly move towards a set of protocols that use XML
encoding for these reasons. </FONT></P>
<P><FONT size=2>As you clearly and correctly point out their applications
cannot really get away completely from ASN.1 - at least yet. They are,
therefore, willing and able to use an API, which as you rightly observe, has
to have ASN.1 parsing capability to pop a key out of a certificate to verify a
signature and do sundry inescapable ASN.1 fiddling. What is however possible
(and to the XML community, desirable) is to increase the XML encoded content
and decrease the ASN.1 encoded content in their environments. I know of
at least one bank that has a team of engineers, which does everything XML
in-house, and need to get a fairly pricey contractor to deal with ASN.1
stuff. They are a canonical representation of what I refer to as the
"XML community".</FONT></P>
<P><FONT size=2>I would suggest that it is reasonable to want to move along a
continuum towards increasing XML encoded content in one's space without
getting all the way there. Just because you can't completely escape
ASN.1 is no reason to continue to do everything in ASN.1.</FONT></P>
<P><FONT size=2>Finally, (suspecting that this will come up) in the debate
over how ASN.1 is more compact and efficient relative to XML I would suggest
we consider one other aspect. In large scale use and deployment the
number of people who can deal with a given technology is a key factor.
The fact that XML is more human readable and easier to deal with is an
efficiency factor that impacts application availability. </FONT></P>
<P><FONT size=2>Khaja</FONT> </P><BR><BR><BR>
<P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From:
Michael Zolotarev</FONT> <BR><FONT size=2>To: Khaja Ahmed; 'Russ Housley ';
'ietf-pkix@imc.org '</FONT> <BR><FONT size=2>Sent: 11/9/00 5:51 PM</FONT>
<BR><FONT size=2>Subject: RE: OCSP-X vs SCVP</FONT> </P>
<P><FONT size=2>Can anyone bother explaining a simple thing to me (I didn't
have my</FONT> <BR><FONT size=2>morning coffee yet, so I'm still mentally a
bit retarded):</FONT> <BR><FONT size=2> </FONT> <BR><FONT size=2>What is
XML community, exactly? Is it a bunch of applications sitting on</FONT>
<BR><FONT size=2>top of XML-messaging backbone? Now then, do those application
call any</FONT> <BR><FONT size=2>APIs at all? Or do they do all the
heavy-weight stuff themselves? I hope</FONT> <BR><FONT size=2>that a concept
of APIs is not totally abandoned in the "XML community".</FONT> <BR><FONT
size=2>Does anybody in the community create PKCS10 in hard way? Or parse
a</FONT> <BR><FONT size=2>certificate, or a CRL by doing it bit-by-bit,
doesn;t matter what the</FONT> <BR><FONT size=2>encoding is? I guess no. They
use APIs.</FONT> <BR><FONT size=2> </FONT> <BR><FONT size=2>If so ( if
not, stop further reading), then obtaining OCSP is just</FONT> <BR><FONT
size=2>another matter for an API. And it absolutely doesn't matter if the
API</FONT> <BR><FONT size=2>uses ASN1 or XML or whatever else. The
XML-community won't see it, and</FONT> <BR><FONT size=2>must't see it. Exactly
as it is for VB community, Fortran community,</FONT> <BR><FONT size=2>Cobol
community and IBM360 mcaro assembler community.</FONT> <BR><FONT
size=2> </FONT> <BR><FONT size=2>Time for my morning coffee. I'll be more
bright when I'm back :) Please</FONT> <BR><FONT size=2>response.</FONT>
<BR><FONT size=2> </FONT> <BR><FONT size=2>Michael</FONT> </P>
<P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Khaja
Ahmed [<A
href="mailto:Khaja.Ahmed@identrus.com">mailto:Khaja.Ahmed@identrus.com</A>]</FONT>
<BR><FONT size=2>Sent: Friday, 10 November 2000 8:27</FONT> <BR><FONT
size=2>To: 'Russ Housley '; 'ietf-pkix@imc.org '</FONT> <BR><FONT
size=2>Subject: RE: OCSP-X vs SCVP</FONT> </P><BR><BR>
<P><FONT size=2>I would even go so far as to say that for the community that
is XML</FONT> <BR><FONT size=2>dependant the nomination you make is the only
workable one.</FONT> </P>
<P><FONT size=2>Khaja </FONT></P>
<P><FONT size=2>-----Original Message----- </FONT><BR><FONT size=2>From: Russ
Housley </FONT><BR><FONT size=2>To: ietf-pkix@imc.org </FONT><BR><FONT
size=2>Sent: 11/9/00 5:11 PM </FONT><BR><FONT size=2>Subject: OCSP-X vs SCVP
</FONT></P>
<P><FONT size=2>A few weeks ago, there was a brief discussion of OCSP-X vs
SCVP. The </FONT><BR><FONT size=2>only </FONT><BR><FONT size=2>consensus
point was that we need to have one PKIX solution for </FONT><BR><FONT
size=2>certification path validation, not two. However, we did not pick
one of</FONT> </P><BR>
<P><FONT size=2>these two alternatives. I think we need to pick
one. We should not put</FONT> </P><BR>
<P><FONT size=2>further efforts into two solutions. </FONT></P>
<P><FONT size=2>There are at least three communities that need to be served by
this </FONT><BR><FONT size=2>protocol: very lightweight clients, organizations
that want centralized </FONT><BR><FONT size=2>control, and clients that do not
parse ASN.1 but understand XML. I am </FONT><BR><FONT size=2>not
</FONT><BR><FONT size=2>sure that there is consensus about these user
groups. If not, we need </FONT><BR><FONT size=2>to </FONT><BR><FONT
size=2>get to consensus ... </FONT></P>
<P><FONT size=2>If these are the user groups that we are trying to satisfy,
then I think</FONT> </P><BR>
<P><FONT size=2>that SCVP is the better answer. </FONT></P>
<P><FONT size=2>Let the debate begin ... </FONT></P>
<P><FONT size=2>Russ </FONT></P></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C04AAB.72A56980--
Received: from home.x509.com (home.x509.com [199.175.150.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06331 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 16:02:58 -0800 (PST)
Received: from xcert.com (trinity.x509.com [199.175.148.59]) by home.x509.com (8.11.0/XCERT) with ESMTP id eAA0A0i41021 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 16:10:00 -0800 (PST)
Sender: marcnarc@xcert.com
Message-ID: <3A0B3C64.96F46E44@xcert.com>
Date: Thu, 09 Nov 2000 16:08:04 -0800
From: Marc Branchaud <marcnarc@xcert.com>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: OCSP-X vs SCVP
References: <D44EACB40164D311BEF00090274EDCCACF8E98@sydneymail1.jp.zergo.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> If so ( if not, stop further reading), then obtaining OCSP is just another
> matter for an API. And it absolutely doesn't matter if the API uses ASN1
> or XML or whatever else. The XML-community won't see it, and must't see it.
> Exactly as it is for VB community, Fortran community, Cobol community and
> IBM360 mcaro assembler community.
Well, somebody has to see the ASN.1, because somebody has to write the API.
Sure, us PKI vendors would be pickled tink if everyone would just buy our
toolkits to do PKI. But that ain't how the world works, and that ain't how
people want it to work.
Of course people will use APIs. But one way to judge the success of a
protocol is by the number of toolkits that support it. I believe that it's
important to design a protocol to be easy to implement, even if the vast
majority of the protocol's users will never care.
(No flames, please! I'm quite happy with either standard. If I've one
criticism, it's that the ASN.1 specs are not free.)
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marcnarc@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
Received: from home.x509.com (home.x509.com [199.175.150.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05928 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 15:52:07 -0800 (PST)
Received: from xcert.com (trinity.x509.com [199.175.148.59]) by home.x509.com (8.11.0/XCERT) with ESMTP id eA9Nx9i40954 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 15:59:09 -0800 (PST)
Sender: marcnarc@xcert.com
Message-ID: <3A0B39D9.17009861@xcert.com>
Date: Thu, 09 Nov 2000 15:57:13 -0800
From: Marc Branchaud <marcnarc@xcert.com>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: The CP Extension (was Re: Extended Key Usage and path validation)
References: <200011092233.RAA11824@roadblock.missi.ncsc.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"David P. Kemp" wrote:
>
> X.509 says:
>
> Typically, different certificate policies will relate to different
> applications which may use the certified key.
>
> and the example under policy mappings refers to policies for "Canadian Trade",
> "U.S. Trade", and "North American Trade".
>
> This example coincides with my impression that the "purposes" referred
> to in new-part1 and the "applications" in X.509 are things which are
> specific to a business domain (banking, DoD, Xcert, VeriSign) rather
> than things which are specific to communication protocols (email, web,
> VPN, ...). If you refer to issuing practices and usages,
> "International Trade" or "Organization A" would be the usage, which
> specifies a policy domain under which "lax" and "strict" are defined.
> Under this interpretation, usage and assurance are not orthogonal;
> Organization B might have a significantly different definition of "lax".
>
I understand that point of view, and I think it's perfectly viable. I also
like your proposed rewording for new-part1:
> Perhaps it would be less ambiguous if new-part1 said:
>
> In an end-entity certificate, each policy information term indicates
> the policy under which the certificate has been issued and the purposes
> for which the certificate may be used.
>
> instead of:
>
> In an end-entity certificate, these policy information terms indicate ...
>
> That would make it clear that there can be more than one term, but each
> term indicates both a certificate policy and some purposes under that policy.
>
I suggest the draft go further, though, and specifically address the point of
view you've described. I suggest that in the KU and EKU sections that the
word "purpose" be replaced with the word "protocol" to make it clear that
these extensions deal with technical matters.
I also suggest that the CP section specifically talk about "organizational
purposes" and "non-technical uses" instead of just "purposes" and "uses".
I'd be happy to suggest some text if people think this is a good idea.
[ snip ]
> A rule of thumb might that KU/EKU specifies things which could be be
> wired into a generic toolkit, but CP specifies things which must be
> decided by application-specific code.
I agree, but I do think the draft should be much clearer about this.
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marcnarc@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05612 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 15:44:33 -0800 (PST)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <W1ALCBKM>; Thu, 9 Nov 2000 18:48:51 -0500
Message-ID: <A105E1C02F5DD31181A500508B5519EC3065AF@blue.identrus.com>
From: Khaja Ahmed <Khaja.Ahmed@identrus.com>
To: "'Michael Zolotarev '" <mzolotarev@baltimore.com>, Khaja Ahmed <Khaja.Ahmed@identrus.com>, "''Russ Housley ' '" <housley@spyrus.com>, "''ietf-pkix@imc.org ' '" <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Thu, 9 Nov 2000 18:48:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04AA7.9C1D11E0"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C04AA7.9C1D11E0
Content-Type: text/plain;
charset="iso-8859-1"
Michael,
Let me begin by saying that, from a purely objective perspective, a
reasonable to good case can be made for either approach. But it isn't about
what approach is technologically / demonstrably more efficient or in some
way better. It has more to do with what the target users of a protocol /
standard / solution want and can use. That is what drives usage of
technology. I do not claim to know what the broad market wants. I just
happen to know what a section (an important one) leans towards.
The XML community I am referring to and am aware of is a group of financial
institutions. (There may be others) These financial institutions have a
group of application and solution developers within their ranks who (most of
them) know and love XML. They prefer to avoid dealing with ASN.1. This XML
community finds it easier to read, deal with and encode information in XML.
They are able to debug protocol implementation problems where XML encoding
is used. They know and are comfortable with XMLDSIG and use that rather than
PKCS#7 to send signed transactions back and forth. They have plans to use
delegated path validation so they will not be doing PKIX section 6.1 stuff
locally. They want to increasingly move towards a set of protocols that use
XML encoding for these reasons.
As you clearly and correctly point out their applications cannot really get
away completely from ASN.1 - at least yet. They are, therefore, willing and
able to use an API, which as you rightly observe, has to have ASN.1 parsing
capability to pop a key out of a certificate to verify a signature and do
sundry inescapable ASN.1 fiddling. What is however possible (and to the XML
community, desirable) is to increase the XML encoded content and decrease
the ASN.1 encoded content in their environments. I know of at least one
bank that has a team of engineers, which does everything XML in-house, and
need to get a fairly pricey contractor to deal with ASN.1 stuff. They are a
canonical representation of what I refer to as the "XML community".
I would suggest that it is reasonable to want to move along a continuum
towards increasing XML encoded content in one's space without getting all
the way there. Just because you can't completely escape ASN.1 is no reason
to continue to do everything in ASN.1.
Finally, (suspecting that this will come up) in the debate over how ASN.1 is
more compact and efficient relative to XML I would suggest we consider one
other aspect. In large scale use and deployment the number of people who
can deal with a given technology is a key factor. The fact that XML is more
human readable and easier to deal with is an efficiency factor that impacts
application availability.
Khaja
-----Original Message-----
From: Michael Zolotarev
To: Khaja Ahmed; 'Russ Housley '; 'ietf-pkix@imc.org '
Sent: 11/9/00 5:51 PM
Subject: RE: OCSP-X vs SCVP
Can anyone bother explaining a simple thing to me (I didn't have my
morning coffee yet, so I'm still mentally a bit retarded):
What is XML community, exactly? Is it a bunch of applications sitting on
top of XML-messaging backbone? Now then, do those application call any
APIs at all? Or do they do all the heavy-weight stuff themselves? I hope
that a concept of APIs is not totally abandoned in the "XML community".
Does anybody in the community create PKCS10 in hard way? Or parse a
certificate, or a CRL by doing it bit-by-bit, doesn;t matter what the
encoding is? I guess no. They use APIs.
If so ( if not, stop further reading), then obtaining OCSP is just
another matter for an API. And it absolutely doesn't matter if the API
uses ASN1 or XML or whatever else. The XML-community won't see it, and
must't see it. Exactly as it is for VB community, Fortran community,
Cobol community and IBM360 mcaro assembler community.
Time for my morning coffee. I'll be more bright when I'm back :) Please
response.
Michael
-----Original Message-----
From: Khaja Ahmed [mailto:Khaja.Ahmed@identrus.com]
Sent: Friday, 10 November 2000 8:27
To: 'Russ Housley '; 'ietf-pkix@imc.org '
Subject: RE: OCSP-X vs SCVP
I would even go so far as to say that for the community that is XML
dependant the nomination you make is the only workable one.
Khaja
-----Original Message-----
From: Russ Housley
To: ietf-pkix@imc.org
Sent: 11/9/00 5:11 PM
Subject: OCSP-X vs SCVP
A few weeks ago, there was a brief discussion of OCSP-X vs SCVP. The
only
consensus point was that we need to have one PKIX solution for
certification path validation, not two. However, we did not pick one of
these two alternatives. I think we need to pick one. We should not put
further efforts into two solutions.
There are at least three communities that need to be served by this
protocol: very lightweight clients, organizations that want centralized
control, and clients that do not parse ASN.1 but understand XML. I am
not
sure that there is consensus about these user groups. If not, we need
to
get to consensus ...
If these are the user groups that we are trying to satisfy, then I think
that SCVP is the better answer.
Let the debate begin ...
Russ
------_=_NextPart_001_01C04AA7.9C1D11E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: OCSP-X vs SCVP</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Michael,</FONT>
</P>
<P><FONT SIZE=3D2>Let me begin by saying that, from a purely objective =
perspective, a reasonable to good case can be made for either =
approach. But it isn't about what approach is technologically / =
demonstrably more efficient or in some way better. It has more to do =
with what the target users of a protocol / standard / solution want and =
can use. That is what drives usage of technology. I do not =
claim to know what the broad market wants. I just happen to know what a =
section (an important one) leans towards.</FONT></P>
<P><FONT SIZE=3D2>The XML community I am referring to and am aware of =
is a group of financial institutions. (There may be others) =
These financial institutions have a group of application and solution =
developers within their ranks who (most of them) know and love =
XML. They prefer to avoid dealing with ASN.1. This XML =
community finds it easier to read, deal with and encode information in =
XML. They are able to debug protocol implementation problems =
where XML encoding is used. They know and are comfortable with XMLDSIG =
and use that rather than PKCS#7 to send signed transactions back and =
forth. They have plans to use delegated path validation so they =
will not be doing PKIX section 6.1 stuff locally. They want to =
increasingly move towards a set of protocols that use XML encoding for =
these reasons. </FONT></P>
<P><FONT SIZE=3D2>As you clearly and correctly point out their =
applications cannot really get away completely from ASN.1 - at least =
yet. They are, therefore, willing and able to use an API, which =
as you rightly observe, has to have ASN.1 parsing capability to pop a =
key out of a certificate to verify a signature and do sundry =
inescapable ASN.1 fiddling. What is however possible (and to the XML =
community, desirable) is to increase the XML encoded content and =
decrease the ASN.1 encoded content in their environments. I know =
of at least one bank that has a team of engineers, which does =
everything XML in-house, and need to get a fairly pricey contractor to =
deal with ASN.1 stuff. They are a canonical representation of =
what I refer to as the "XML community".</FONT></P>
<P><FONT SIZE=3D2>I would suggest that it is reasonable to want to move =
along a continuum towards increasing XML encoded content in one's space =
without getting all the way there. Just because you can't =
completely escape ASN.1 is no reason to continue to do everything in =
ASN.1.</FONT></P>
<P><FONT SIZE=3D2>Finally, (suspecting that this will come up) in the =
debate over how ASN.1 is more compact and efficient relative to XML I =
would suggest we consider one other aspect. In large scale use =
and deployment the number of people who can deal with a given =
technology is a key factor. The fact that XML is more human =
readable and easier to deal with is an efficiency factor that impacts =
application availability. </FONT></P>
<P><FONT SIZE=3D2>Khaja</FONT>
</P>
<BR>
<BR>
<BR>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Zolotarev</FONT>
<BR><FONT SIZE=3D2>To: Khaja Ahmed; 'Russ Housley '; 'ietf-pkix@imc.org =
'</FONT>
<BR><FONT SIZE=3D2>Sent: 11/9/00 5:51 PM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP-X vs SCVP</FONT>
</P>
<P><FONT SIZE=3D2>Can anyone bother explaining a simple thing to me (I =
didn't have my</FONT>
<BR><FONT SIZE=3D2>morning coffee yet, so I'm still mentally a bit =
retarded):</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>What is XML community, exactly? Is it a bunch of =
applications sitting on</FONT>
<BR><FONT SIZE=3D2>top of XML-messaging backbone? Now then, do those =
application call any</FONT>
<BR><FONT SIZE=3D2>APIs at all? Or do they do all the heavy-weight =
stuff themselves? I hope</FONT>
<BR><FONT SIZE=3D2>that a concept of APIs is not totally abandoned in =
the "XML community".</FONT>
<BR><FONT SIZE=3D2>Does anybody in the community create PKCS10 in hard =
way? Or parse a</FONT>
<BR><FONT SIZE=3D2>certificate, or a CRL by doing it bit-by-bit, =
doesn;t matter what the</FONT>
<BR><FONT SIZE=3D2>encoding is? I guess no. They use APIs.</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>If so ( if not, stop further reading), then =
obtaining OCSP is just</FONT>
<BR><FONT SIZE=3D2>another matter for an API. And it absolutely doesn't =
matter if the API</FONT>
<BR><FONT SIZE=3D2>uses ASN1 or XML or whatever else. The XML-community =
won't see it, and</FONT>
<BR><FONT SIZE=3D2>must't see it. Exactly as it is for VB community, =
Fortran community,</FONT>
<BR><FONT SIZE=3D2>Cobol community and IBM360 mcaro assembler =
community.</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>Time for my morning coffee. I'll be more bright when =
I'm back :) Please</FONT>
<BR><FONT SIZE=3D2>response.</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>Michael</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Khaja Ahmed [<A =
HREF=3D"mailto:Khaja.Ahmed@identrus.com">mailto:Khaja.Ahmed@identrus.com=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, 10 November 2000 8:27</FONT>
<BR><FONT SIZE=3D2>To: 'Russ Housley '; 'ietf-pkix@imc.org '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP-X vs SCVP</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>I would even go so far as to say that for the =
community that is XML</FONT>
<BR><FONT SIZE=3D2>dependant the nomination you make is the only =
workable one.</FONT>
</P>
<P><FONT SIZE=3D2>Khaja </FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Russ Housley </FONT>
<BR><FONT SIZE=3D2>To: ietf-pkix@imc.org </FONT>
<BR><FONT SIZE=3D2>Sent: 11/9/00 5:11 PM </FONT>
<BR><FONT SIZE=3D2>Subject: OCSP-X vs SCVP </FONT>
</P>
<P><FONT SIZE=3D2>A few weeks ago, there was a brief discussion of =
OCSP-X vs SCVP. The </FONT>
<BR><FONT SIZE=3D2>only </FONT>
<BR><FONT SIZE=3D2>consensus point was that we need to have one PKIX =
solution for </FONT>
<BR><FONT SIZE=3D2>certification path validation, not two. =
However, we did not pick one of</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>these two alternatives. I think we need to pick =
one. We should not put</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>further efforts into two solutions. </FONT>
</P>
<P><FONT SIZE=3D2>There are at least three communities that need to be =
served by this </FONT>
<BR><FONT SIZE=3D2>protocol: very lightweight clients, organizations =
that want centralized </FONT>
<BR><FONT SIZE=3D2>control, and clients that do not parse ASN.1 but =
understand XML. I am </FONT>
<BR><FONT SIZE=3D2>not </FONT>
<BR><FONT SIZE=3D2>sure that there is consensus about these user =
groups. If not, we need </FONT>
<BR><FONT SIZE=3D2>to </FONT>
<BR><FONT SIZE=3D2>get to consensus ... </FONT>
</P>
<P><FONT SIZE=3D2>If these are the user groups that we are trying to =
satisfy, then I think</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>that SCVP is the better answer. </FONT>
</P>
<P><FONT SIZE=3D2>Let the debate begin ... </FONT>
</P>
<P><FONT SIZE=3D2>Russ </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C04AA7.9C1D11E0--
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04014 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 14:49:27 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id RAA11828; Thu, 9 Nov 2000 17:34:00 -0500 (EST)
Message-Id: <200011092233.RAA11824@roadblock.missi.ncsc.mil>
Date: Thu, 9 Nov 2000 17:48:38 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: The CP Extension (was Re: Extended Key Usage and path validation)
To: ietf-pkix@imc.org, marcnarc@xcert.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: KTs/fZDOptALQTzleSXv9A==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
> From: Marc Branchaud <marcnarc@xcert.com>
>
> Section 4.2.1.5 of draft-ietf-pkix-new-part1-02.txt states:
>
> In an end-entity certificate, these policy information terms indicate
> the policy under which the certificate has been issued and the pur-
> poses for which the certificate may be used. In a CA certificate,
> these policy information terms limit the set of policies for certifi-
> cation paths which include this certificate. When a CA does not wish
> to limit the set of policies for certification paths which include
> this certificate, they may assert the special policy anyPolicy, with
> a value of {2 5 29 32 0}.
>
> I take this to mean that the CP extension is specifically about both
> certification practices (i.e. cert issuing policy) _and_ certificate use. I
> see nothing here that says you can't use a CP extension in a CA cert to limit
> the uses of subsequent certs in a chain.
X.509 says:
Typically, different certificate policies will relate to different
applications which may use the certified key.
and the example under policy mappings refers to policies for "Canadian Trade",
"U.S. Trade", and "North American Trade".
This example coincides with my impression that the "purposes" referred
to in new-part1 and the "applications" in X.509 are things which are
specific to a business domain (banking, DoD, Xcert, VeriSign) rather
than things which are specific to communication protocols (email, web,
VPN, ...). If you refer to issuing practices and usages,
"International Trade" or "Organization A" would be the usage, which
specifies a policy domain under which "lax" and "strict" are defined.
Under this interpretation, usage and assurance are not orthogonal;
Organization B might have a significantly different definition of "lax".
Perhaps it would be less ambiguous if new-part1 said:
In an end-entity certificate, each policy information term indicates
the policy under which the certificate has been issued and the purposes
for which the certificate may be used.
instead of:
In an end-entity certificate, these policy information terms indicate ...
That would make it clear that there can be more than one term, but each
term indicates both a certificate policy and some purposes under that policy.
> It seems to me that cert usage limitations are all supposed to be expressed
> in the policies extension. Indeed, I expect that most deployments would
> define separate policy OIDs to represent both issuing practices and usage
> policies, because the two are quite orthogonal. An organization might, for
> example, have "lax" and "strict" issuing processes, and might have three uses
> for its certificates ("login", "email" and "purchasing"). For whatever
> reasons, it may want to be able to mix & match issuing processes with uses
> ("lax" with "login", or "strict" with "purchasing"). All this is supposed to
> be expressed through OIDs in the CP extension.
I agree that "purchasing" might be a purpose, but I don't agree that
"login" and "email" are the purposes envisioned by Certificate
Policies. You can conduct purchasing transactions over email, over the
web, over IPsec connections, or through an EDI VAN. Purchasing also
might involve both confidentiality and signatures. The low-level OS
operations (login), communication protocol (email) and crypto functions
(signature) are controlled by KU/EKU. The business-level purposes
(purchasing less than $10K, access to grade-B sensitive information,
...) are the ones which a Certificate Policy is intended to address.
A rule of thumb might that KU/EKU specifies things which could be be
wired into a generic toolkit, but CP specifies things which must be
decided by application-specific code.
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03860 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 14:47:01 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA16007; Fri, 10 Nov 2000 09:01:04 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <WRV4VN27>; Fri, 10 Nov 2000 09:52:01 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCACF8E98@sydneymail1.jp.zergo.com.au>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Khaja Ahmed <Khaja.Ahmed@identrus.com>, "'Russ Housley '" <housley@spyrus.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Fri, 10 Nov 2000 09:51:59 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04A9F.AB250740"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C04A9F.AB250740
Content-Type: text/plain;
charset="iso-8859-1"
Can anyone bother explaining a simple thing to me (I didn't have my morning
coffee yet, so I'm still mentally a bit retarded):
What is XML community, exactly? Is it a bunch of applications sitting on top
of XML-messaging backbone? Now then, do those application call any APIs at
all? Or do they do all the heavy-weight stuff themselves? I hope that a
concept of APIs is not totally abandoned in the "XML community". Does
anybody in the community create PKCS10 in hard way? Or parse a certificate,
or a CRL by doing it bit-by-bit, doesn;t matter what the encoding is? I
guess no. They use APIs.
If so ( if not, stop further reading), then obtaining OCSP is just another
matter for an API. And it absolutely doesn't matter if the API uses ASN1 or
XML or whatever else. The XML-community won't see it, and must't see it.
Exactly as it is for VB community, Fortran community, Cobol community and
IBM360 mcaro assembler community.
Time for my morning coffee. I'll be more bright when I'm back :) Please
response.
Michael
-----Original Message-----
From: Khaja Ahmed [mailto:Khaja.Ahmed@identrus.com]
Sent: Friday, 10 November 2000 8:27
To: 'Russ Housley '; 'ietf-pkix@imc.org '
Subject: RE: OCSP-X vs SCVP
I would even go so far as to say that for the community that is XML
dependant the nomination you make is the only workable one.
Khaja
-----Original Message-----
From: Russ Housley
To: ietf-pkix@imc.org
Sent: 11/9/00 5:11 PM
Subject: OCSP-X vs SCVP
A few weeks ago, there was a brief discussion of OCSP-X vs SCVP. The
only
consensus point was that we need to have one PKIX solution for
certification path validation, not two. However, we did not pick one of
these two alternatives. I think we need to pick one. We should not put
further efforts into two solutions.
There are at least three communities that need to be served by this
protocol: very lightweight clients, organizations that want centralized
control, and clients that do not parse ASN.1 but understand XML. I am
not
sure that there is consensus about these user groups. If not, we need
to
get to consensus ...
If these are the user groups that we are trying to satisfy, then I think
that SCVP is the better answer.
Let the debate begin ...
Russ
------_=_NextPart_001_01C04A9F.AB250740
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: OCSP-X vs SCVP</TITLE>
<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=272074123-09112000><FONT face=Arial color=#0000ff size=2>Can
anyone bother explaining a simple thing to me (I didn't have my morning coffee
yet, so I'm still mentally a bit retarded):</FONT></SPAN></DIV>
<DIV><SPAN class=272074123-09112000><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=272074123-09112000><FONT face=Arial color=#0000ff size=2>What
is XML community, exactly? Is it a bunch of applications sitting on top of
XML-messaging backbone? Now then, do those application call any APIs at all? Or
do they do all the heavy-weight stuff themselves? I hope that a concept of APIs
is not totally abandoned in the "XML community". Does anybody in the community
create PKCS10 in hard way? Or parse a certificate, or a CRL by doing it
bit-by-bit, doesn;t matter what the encoding is? I guess no. They use
APIs.</FONT></SPAN></DIV>
<DIV><SPAN class=272074123-09112000><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=272074123-09112000><FONT face=Arial color=#0000ff size=2>If so
( if not, stop further reading), then obtaining OCSP is just another matter
for an API. And it absolutely doesn't matter if the API uses ASN1 or XML or
whatever else. The XML-community won't see it, and must't see it. Exactly as it
is for VB community, Fortran community, Cobol community and IBM360 mcaro
assembler community.</FONT></SPAN></DIV>
<DIV><SPAN class=272074123-09112000><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=272074123-09112000><FONT face=Arial color=#0000ff size=2>Time
for my morning coffee. I'll be more bright when I'm back :) Please
response.</FONT></SPAN></DIV>
<DIV><SPAN class=272074123-09112000><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=272074123-09112000><FONT face=Arial color=#0000ff
size=2>Michael</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Khaja Ahmed
[mailto:Khaja.Ahmed@identrus.com]<BR><B>Sent:</B> Friday, 10 November 2000
8:27<BR><B>To:</B> 'Russ Housley '; 'ietf-pkix@imc.org '<BR><B>Subject:</B>
RE: OCSP-X vs SCVP<BR><BR></FONT></DIV>
<P><FONT size=2>I would even go so far as to say that for the community that
is XML dependant the nomination you make is the only workable one.</FONT></P>
<P><FONT size=2>Khaja</FONT> </P>
<P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Russ
Housley</FONT> <BR><FONT size=2>To: ietf-pkix@imc.org</FONT> <BR><FONT
size=2>Sent: 11/9/00 5:11 PM</FONT> <BR><FONT size=2>Subject: OCSP-X vs
SCVP</FONT> </P>
<P><FONT size=2>A few weeks ago, there was a brief discussion of OCSP-X vs
SCVP. The</FONT> <BR><FONT size=2>only </FONT><BR><FONT size=2>consensus
point was that we need to have one PKIX solution for </FONT><BR><FONT
size=2>certification path validation, not two. However, we did not pick
one of</FONT> </P>
<P><FONT size=2>these two alternatives. I think we need to pick
one. We should not put</FONT> </P>
<P><FONT size=2>further efforts into two solutions.</FONT> </P>
<P><FONT size=2>There are at least three communities that need to be served by
this </FONT><BR><FONT size=2>protocol: very lightweight clients, organizations
that want centralized </FONT><BR><FONT size=2>control, and clients that do not
parse ASN.1 but understand XML. I am</FONT> <BR><FONT size=2>not
</FONT><BR><FONT size=2>sure that there is consensus about these user
groups. If not, we need</FONT> <BR><FONT size=2>to </FONT><BR><FONT
size=2>get to consensus ...</FONT> </P>
<P><FONT size=2>If these are the user groups that we are trying to satisfy,
then I think</FONT> </P>
<P><FONT size=2>that SCVP is the better answer.</FONT> </P>
<P><FONT size=2>Let the debate begin ...</FONT> </P>
<P><FONT size=2>Russ</FONT> </P></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C04A9F.AB250740--
Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03156 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 14:22:34 -0800 (PST)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <W1ALCBJK>; Thu, 9 Nov 2000 17:26:37 -0500
Message-ID: <A105E1C02F5DD31181A500508B5519EC3065AC@blue.identrus.com>
From: Khaja Ahmed <Khaja.Ahmed@identrus.com>
To: "'Russ Housley '" <housley@spyrus.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: OCSP-X vs SCVP
Date: Thu, 9 Nov 2000 17:26:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04A9C.1F179A60"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C04A9C.1F179A60
Content-Type: text/plain;
charset="iso-8859-1"
I would even go so far as to say that for the community that is XML
dependant the nomination you make is the only workable one.
Khaja
-----Original Message-----
From: Russ Housley
To: ietf-pkix@imc.org
Sent: 11/9/00 5:11 PM
Subject: OCSP-X vs SCVP
A few weeks ago, there was a brief discussion of OCSP-X vs SCVP. The
only
consensus point was that we need to have one PKIX solution for
certification path validation, not two. However, we did not pick one of
these two alternatives. I think we need to pick one. We should not put
further efforts into two solutions.
There are at least three communities that need to be served by this
protocol: very lightweight clients, organizations that want centralized
control, and clients that do not parse ASN.1 but understand XML. I am
not
sure that there is consensus about these user groups. If not, we need
to
get to consensus ...
If these are the user groups that we are trying to satisfy, then I think
that SCVP is the better answer.
Let the debate begin ...
Russ
------_=_NextPart_001_01C04A9C.1F179A60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: OCSP-X vs SCVP</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>I would even go so far as to say that for the =
community that is XML dependant the nomination you make is the only =
workable one.</FONT></P>
<P><FONT SIZE=3D2>Khaja</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Russ Housley</FONT>
<BR><FONT SIZE=3D2>To: ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>Sent: 11/9/00 5:11 PM</FONT>
<BR><FONT SIZE=3D2>Subject: OCSP-X vs SCVP</FONT>
</P>
<P><FONT SIZE=3D2>A few weeks ago, there was a brief discussion of =
OCSP-X vs SCVP. The</FONT>
<BR><FONT SIZE=3D2>only </FONT>
<BR><FONT SIZE=3D2>consensus point was that we need to have one PKIX =
solution for </FONT>
<BR><FONT SIZE=3D2>certification path validation, not two. =
However, we did not pick one of</FONT>
</P>
<P><FONT SIZE=3D2>these two alternatives. I think we need to pick =
one. We should not put</FONT>
</P>
<P><FONT SIZE=3D2>further efforts into two solutions.</FONT>
</P>
<P><FONT SIZE=3D2>There are at least three communities that need to be =
served by this </FONT>
<BR><FONT SIZE=3D2>protocol: very lightweight clients, organizations =
that want centralized </FONT>
<BR><FONT SIZE=3D2>control, and clients that do not parse ASN.1 but =
understand XML. I am</FONT>
<BR><FONT SIZE=3D2>not </FONT>
<BR><FONT SIZE=3D2>sure that there is consensus about these user =
groups. If not, we need</FONT>
<BR><FONT SIZE=3D2>to </FONT>
<BR><FONT SIZE=3D2>get to consensus ...</FONT>
</P>
<P><FONT SIZE=3D2>If these are the user groups that we are trying to =
satisfy, then I think</FONT>
</P>
<P><FONT SIZE=3D2>that SCVP is the better answer.</FONT>
</P>
<P><FONT SIZE=3D2>Let the debate begin ...</FONT>
</P>
<P><FONT SIZE=3D2>Russ</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C04A9C.1F179A60--
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02579 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 14:04:20 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA16554 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 14:10:46 -0800 (PST)
Message-Id: <4.3.2.7.2.20001109164409.01a89858@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 09 Nov 2000 17:11:21 -0500
To: ietf-pkix@imc.org
From: Russ Housley <housley@spyrus.com>
Subject: OCSP-X vs SCVP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
A few weeks ago, there was a brief discussion of OCSP-X vs SCVP. The only
consensus point was that we need to have one PKIX solution for
certification path validation, not two. However, we did not pick one of
these two alternatives. I think we need to pick one. We should not put
further efforts into two solutions.
There are at least three communities that need to be served by this
protocol: very lightweight clients, organizations that want centralized
control, and clients that do not parse ASN.1 but understand XML. I am not
sure that there is consensus about these user groups. If not, we need to
get to consensus ...
If these are the user groups that we are trying to satisfy, then I think
that SCVP is the better answer.
Let the debate begin ...
Russ
Received: from mx.sita.int (mx2.sita.int [57.250.224.238]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00663 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 12:38:25 -0800 (PST)
From: Patrick.Patterson@sita.int
Received: from montreal1.yul.sita.int (montreal1.yul.sita.int [57.4.233.253]) by mx.sita.int with SMTP id eA9Kiv324559; Thu, 9 Nov 2000 20:44:57 GMT
Received: by montreal1.yul.sita.int(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 05256992.0071F40F ; Thu, 9 Nov 2000 15:44:40 -0500
X-Lotus-FromDomain: SITA
To: Marc Branchaud <marcnarc@xcert.com>
cc: ietf-pkix@imc.org
Message-ID: <05256992.0071F39F.00@montreal1.yul.sita.int>
Date: Thu, 9 Nov 2000 20:44:36 +0000
Subject: Re: The CP Extension (was Re: Extended Key Usage and path validation)
Mime-Version: 1.0
Content-type: multipart/mixed; Boundary="0__=38fFqlhj5Y2rrkqEAXPNAgHk7Pv0CSwoiMxGjY1tCihOdzlqvqK511lu"
Content-Disposition: inline
--0__=38fFqlhj5Y2rrkqEAXPNAgHk7Pv0CSwoiMxGjY1tCihOdzlqvqK511lu
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
I'll second the confusion:
but for a slightly different reason: Having both Certificate Policy OIDs (that
tie a given X.509 Certificate to a given Certificate Policy) and Usage Policy
OID's (which is what I think these should be correctly called) mixed in the same
extension is a "Bad Thing" in my opinion - a given Certificate Policy should
state categorically what is an allowed function, and what is not an allowed
function. I guess that I don't see how the "mix and match" scenario would be
written into the policies - "You can write e-mail all of the time, but only
certificates issued on the third monday of the month may have the purchasing
flag extended" - I'll admit that this is an extreme example, but in my mind - if
you want a certificate to be usable for different things, create them under
different policies (and thus different OIDs) - to borrow the analogy from
below: have Lax and E-mail be one certificate policy, and strict and purchasing
be another.
This still doesn't address the idea where all of this started: The need to have
some way of having an application check for usage validity of a given
certificate type, but I'm going to hold to my position that the Certificate
Policy field is not the place to do this.
Patrick.
________________________________________________________________________________________
>From Marc Branchaud <marcnarc@xcert.com> on 9 November 2000 7:07:54 PM
To : ietf-pkix@imc.org
Copy To : (bcc: Patrick Patterson)
Subject : The CP Extension (was Re: Extended Key Usage and path validation)
--0__=38fFqlhj5Y2rrkqEAXPNAgHk7Pv0CSwoiMxGjY1tCihOdzlqvqK511lu
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
"David P. Kemp" wrote:
>
> I agree with Patrick Patterson and Michael Str=F6der that using the
> Certificate Policies extension to control usage of the EE key
> "messes with" the CP extension. The policy under which certificates
> are issued seems tenuously related, if not completely unrelated,
> to the applications which make use of the certificates.
>
OK, I'm confused.
Section 4.2.1.5 of draft-ietf-pkix-new-part1-02.txt states:
In an end-entity certificate, these policy information terms indicat=
e
the policy under which the certificate has been issued and the pur-
poses for which the certificate may be used. In a CA certificate,
these policy information terms limit the set of policies for certifi=
-
cation paths which include this certificate. When a CA does not wish=
to limit the set of policies for certification paths which include
this certificate, they may assert the special policy anyPolicy, with=
a value of {2 5 29 32 0}.
I take this to mean that the CP extension is specifically about both
certification practices (i.e. cert issuing policy) _and_ certificate us=
e. I
see nothing here that says you can't use a CP extension in a CA cert to=
limit
the uses of subsequent certs in a chain.
> We have basic constraints, name constraints, and policy constraints,
> all of which limit the capabilities of lower CAs and EEs.
I disagree with you here about the policy constraints extension. That
extension merely sets limits on the extent to which policies are applie=
d in
chain processing, but it does _not_ explicitly define or limit any
capabilities.
It seems to me that cert usage limitations are all supposed to be expre=
ssed
in the policies extension. Indeed, I expect that most deployments woul=
d
define separate policy OIDs to represent both issuing practices and usa=
ge
policies, because the two are quite orthogonal. An organization might,=
for
example, have "lax" and "strict" issuing processes, and might have thre=
e uses
for its certificates ("login", "email" and "purchasing"). For whatever=
reasons, it may want to be able to mix & match issuing processes with u=
ses
("lax" with "login", or "strict" with "purchasing"). All this is suppo=
sed to
be expressed through OIDs in the CP extension.
> I'm not convinced that EKU serves a useful purpose. And if EKU itsel=
f
> is useful, I'm even less convinced that constraining it at the CA
> level, whatever the mechanism, is useful. If you want EKUs, and you
> don't trust a CA to issue EE certs with proper EKUs, then you shouldn=
't
> accept the CA. But if there is a need to use EKU, and to limit it by=
> CA, then that need should be satisfied with a clean mechanism, not by=
> bastardizing the CP extension.
Both EKU and CP are quite similar (one's just an OID, the other's just =
an OID
with some qualifying info). I tend to agree that EKU is currently a bi=
t
redundant, but it seems to me that having two different extensions to a=
ddress
issuing and usage policies might be a good thing. EKU seems a good can=
didate
to identify the usage policies, leaving CP solely for issuing policies.=
This
would require, as you say, a new mechanism ("EKU Constraints extension"=
perhaps?) to manage the EKU policies. There would also have to be an
understanding, I think, that a CA with, say, an "email" usage OID only =
means
that the CA is allowed to issue certs with that OID (not that the CA ca=
n
somehow be used for signing S/MIME messages).
Marc
+----------------------------------------------------------------------=
--+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL I=
NC.
marcnarc@xcert.com PKI References page: www.xcert.=
com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+----------------------------------------------------------------------=
--+
------
Patrick Patterson
PKI Expert, IPVAS CA
SITA/Equant JV.
=
--0__=38fFqlhj5Y2rrkqEAXPNAgHk7Pv0CSwoiMxGjY1tCihOdzlqvqK511lu--
Received: from home.x509.com (home.x509.com [199.175.150.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25509 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 11:02:49 -0800 (PST)
Received: from xcert.com (trinity.x509.com [199.175.148.59]) by home.x509.com (8.11.0/XCERT) with ESMTP id eA9J9oi39147 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 11:09:50 -0800 (PST)
Sender: marcnarc@xcert.com
Message-ID: <3A0AF60A.C22DF49D@xcert.com>
Date: Thu, 09 Nov 2000 11:07:54 -0800
From: Marc Branchaud <marcnarc@xcert.com>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: The CP Extension (was Re: Extended Key Usage and path validation)
References: <200011091639.LAA13549@roadblock.missi.ncsc.mil>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
"David P. Kemp" wrote:
>
> I agree with Patrick Patterson and Michael Ströder that using the
> Certificate Policies extension to control usage of the EE key
> "messes with" the CP extension. The policy under which certificates
> are issued seems tenuously related, if not completely unrelated,
> to the applications which make use of the certificates.
>
OK, I'm confused.
Section 4.2.1.5 of draft-ietf-pkix-new-part1-02.txt states:
In an end-entity certificate, these policy information terms indicate
the policy under which the certificate has been issued and the pur-
poses for which the certificate may be used. In a CA certificate,
these policy information terms limit the set of policies for certifi-
cation paths which include this certificate. When a CA does not wish
to limit the set of policies for certification paths which include
this certificate, they may assert the special policy anyPolicy, with
a value of {2 5 29 32 0}.
I take this to mean that the CP extension is specifically about both
certification practices (i.e. cert issuing policy) _and_ certificate use. I
see nothing here that says you can't use a CP extension in a CA cert to limit
the uses of subsequent certs in a chain.
> We have basic constraints, name constraints, and policy constraints,
> all of which limit the capabilities of lower CAs and EEs.
I disagree with you here about the policy constraints extension. That
extension merely sets limits on the extent to which policies are applied in
chain processing, but it does _not_ explicitly define or limit any
capabilities.
It seems to me that cert usage limitations are all supposed to be expressed
in the policies extension. Indeed, I expect that most deployments would
define separate policy OIDs to represent both issuing practices and usage
policies, because the two are quite orthogonal. An organization might, for
example, have "lax" and "strict" issuing processes, and might have three uses
for its certificates ("login", "email" and "purchasing"). For whatever
reasons, it may want to be able to mix & match issuing processes with uses
("lax" with "login", or "strict" with "purchasing"). All this is supposed to
be expressed through OIDs in the CP extension.
> I'm not convinced that EKU serves a useful purpose. And if EKU itself
> is useful, I'm even less convinced that constraining it at the CA
> level, whatever the mechanism, is useful. If you want EKUs, and you
> don't trust a CA to issue EE certs with proper EKUs, then you shouldn't
> accept the CA. But if there is a need to use EKU, and to limit it by
> CA, then that need should be satisfied with a clean mechanism, not by
> bastardizing the CP extension.
Both EKU and CP are quite similar (one's just an OID, the other's just an OID
with some qualifying info). I tend to agree that EKU is currently a bit
redundant, but it seems to me that having two different extensions to address
issuing and usage policies might be a good thing. EKU seems a good candidate
to identify the usage policies, leaving CP solely for issuing policies. This
would require, as you say, a new mechanism ("EKU Constraints extension"
perhaps?) to manage the EKU policies. There would also have to be an
understanding, I think, that a CA with, say, an "email" usage OID only means
that the CA is allowed to issue certs with that OID (not that the CA can
somehow be used for signing S/MIME messages).
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marcnarc@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19264 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 08:54:31 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA13557 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 11:39:08 -0500 (EST)
Message-Id: <200011091639.LAA13549@roadblock.missi.ncsc.mil>
Date: Thu, 9 Nov 2000 11:54:00 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: Extended Key Usage and path validation
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=ISO-8859-1
Content-MD5: WCTqVLkPfS2/8+CHN+zEdA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id IAA19265
> From: thayes@netscape.com (Terry Hayes)
>
> A CA can put this global OID into the CertificatePolicies along with
> OIDs for its own more specific or more constrained policies. The
> extension can handle more than one OID.
>
> > [Patrick.Patterson@sita.int]
> > I know the issue here is that we need some technical way to assure that a given
> > certificate isn't used for something that it was not intended for, but I'm not
> > sure that either the current method or your proposed fix is the way it should
> > go. Shouldn't this be something that an attribute certificate be used for, or am
> > I completely off the mark with that?
I agree with Steve Kent that putting an EKU in a CA certificate which does
not apply to the CA's key is a misusage of that extension.
I agree with Patrick Patterson and Michael Ströder that using the
Certificate Policies extension to control usage of the EE key
"messes with" the CP extension. The policy under which certificates
are issued seems tenuously related, if not completely unrelated,
to the applications which make use of the certificates.
We have basic constraints, name constraints, and policy constraints,
all of which limit the capabilities of lower CAs and EEs. And PKIX has
defined AIA and SIA private (non-X.509) extensions. If it really is
necessary for a CA to constrain the usage of an End Entity's key,
shouldn't we be defining a PKIX-private "EKU Constraints" extension to
be placed in CA certificates?
I'm not convinced that EKU serves a useful purpose. And if EKU itself
is useful, I'm even less convinced that constraining it at the CA
level, whatever the mechanism, is useful. If you want EKUs, and you
don't trust a CA to issue EE certs with proper EKUs, then you shouldn't
accept the CA. But if there is a need to use EKU, and to limit it by
CA, then that need should be satisfied with a clean mechanism, not by
bastardizing the CP extension.
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16270 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 08:20:33 -0800 (PST)
Received: from mega (t6o69p15.telia.com [213.64.110.135]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id RAA05390; Thu, 9 Nov 2000 17:27:27 +0100 (CET)
Message-ID: <014101c04a69$c2a1d0a0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Steve Hanna" <steve.hanna@sun.com>
Cc: <ietf-pkix@imc.org>
References: <3A09AEB7.D7F6E184@sun.com> <001501c04a21$4b33dc40$0201a8c0@vincent.se> <3A0AAE25.E1BCDAEA@sun.com> <00e401c04a5b$f92eb100$0201a8c0@vincent.se> <3A0ABF72.3AB935F5@sun.com>
Subject: Re: AC Scenarios - PULL model
Date: Thu, 9 Nov 2000 17:26:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA16272
Steve,
<snip>
> Frankly, I do not find it useful for you to claim you have found scaling
> problems, security problems, or other problems if you cannot describe in
> clear and unambiguous terms what those problems are. Vague
> pronouncements such as the ones in your most recent notes are more often
> the cause of scaling and security problems than a solution to them.
Pardon me if I have been unclear, but when somebody refer to "scaling problems" people
(apparently) put different meaning in that word. In the AC PULL scenario the scaling
problem is that it depends on centrally issued ACs. This is incompatible
with how organizations relate and interact with each other, and to their employees.
I.e. either an individual/employee is given authority directly by the verifying organization
(hardly requing an AC) or by his/her own organization (= multiple AAs required).
And as Polar H recently concluded (and I have said in this very list a number of times),
AC PULL is probably a no-issue, as ACs are pretty redundant in the rather
limited scenarios explicitly and implicitly imposed by the AC PULL model .
So please let us go back to the PUSH-thread which is much more interesting!
<snip>
Anders
Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15804 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 08:04:30 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id LAA16165; Thu, 9 Nov 2000 11:07:00 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 9 Nov 2000 11:06:59 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: Steve Hanna <steve.hanna@sun.com>
cc: Anders Rundgren <anders.rundgren@telia.com>, ietf-pkix@imc.org
Subject: Re: AC Scenarios - PULL model
In-Reply-To: <3A0AC756.C9471B44@sun.com>
Message-ID: <Pine.LNX.4.10.10011091057570.143-100000@marcy.adiron.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 9 Nov 2000, Steve Hanna wrote:
> Polar Humenn wrote:
> > In the CORBA Security Case, an object reference is configured with a
> > specification of where and how the client is supposed to find the
> > authorization information (which can be an X.509 AC, or one of these XML
> > thinggys) the object will understand. It is an authorization token layer
> > acquisition service, which we call ATLAS. It is up to the client to
> > contact that service and acquire the AC's (or whatever) based on its
> > authentication to the ATLAS. Then the client can push the ACs to the
> > object during a CORBA request.
>
> OK. So it's a push model. How does the client authenticate to the
> object?
Well, it "can" be a push model. Nothing can stop it from being a pull
model, of course. :)
The client may authenticate using SSL or SECIOP-GSS-Kerberos, or any
SECIOP protocol that uses GSS-API based mechanisms. SECIOP is a messaging
protocol for CORBA to transport GSS tokens.
My point was, that in CORBA Security, every object states where and how (A
CORBA service, or otherwise) the client is to the get ACs in its object
reference. That's how we gain interoperability in the general case.
> > In the pull scenario, you don't really need AC's at all. All you need is a
> > answer from a trusted somebody about the subject. It could be your
> > babysitter has a kerberos connection to your mother, who said you can play
> > outside. (no AC signature verification needed). I.e. your mother doesn't
> > have to sign a note, she can just tell the babysitter when asked.
>
> Agreed. You don't have to use ACs in the pull scenario. But that's what
> we're discussing here.
True. I just wanted to state that there is no *requirement* for ACs in a
pull model, although you can certainly use them, verify them, etc.
Cheers,
-Polar
-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:polar@adiron.com 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15121 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 07:43:51 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16970; Thu, 9 Nov 2000 08:50:47 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA12052; Thu, 9 Nov 2000 10:50:46 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA02861; Thu, 9 Nov 2000 10:50:45 -0500 (EST)
Message-ID: <3A0AC756.C9471B44@sun.com>
Date: Thu, 09 Nov 2000 10:48:38 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <polar@adiron.com>
CC: Anders Rundgren <anders.rundgren@telia.com>, ietf-pkix@imc.org
Subject: Re: AC Scenarios - PULL model
References: <Pine.LNX.4.10.10011090943380.143-100000@marcy.adiron.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Polar Humenn wrote:
> In the CORBA Security Case, an object reference is configured with a
> specification of where and how the client is supposed to find the
> authorization information (which can be an X.509 AC, or one of these XML
> thinggys) the object will understand. It is an authorization token layer
> acquisition service, which we call ATLAS. It is up to the client to
> contact that service and acquire the AC's (or whatever) based on its
> authentication to the ATLAS. Then the client can push the ACs to the
> object during a CORBA request.
OK. So it's a push model. How does the client authenticate to the
object?
> In the pull scenario, you don't really need AC's at all. All you need is a
> answer from a trusted somebody about the subject. It could be your
> babysitter has a kerberos connection to your mother, who said you can play
> outside. (no AC signature verification needed). I.e. your mother doesn't
> have to sign a note, she can just tell the babysitter when asked.
Agreed. You don't have to use ACs in the pull scenario. But that's what
we're discussing here.
-Steve
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08975 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 07:10:17 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24381; Thu, 9 Nov 2000 07:17:10 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA18813; Thu, 9 Nov 2000 10:17:06 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA00302; Thu, 9 Nov 2000 10:17:05 -0500 (EST)
Message-ID: <3A0ABF72.3AB935F5@sun.com>
Date: Thu, 09 Nov 2000 10:14:58 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: ietf-pkix@imc.org
Subject: Re: AC Scenarios - PULL model
References: <3A09AEB7.D7F6E184@sun.com> <001501c04a21$4b33dc40$0201a8c0@vincent.se> <3A0AAE25.E1BCDAEA@sun.com> <00e401c04a5b$f92eb100$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote:
> > ac509prof (section 5) says that "The AC issuer MUST be directly trusted
> > as an AC issuer (by configuration or otherwise)." It also says (section
> > 1.1) "This specification deals with the simple cases where one authority
> > issues all of the ACs for a particular set of attributes."
> >
> > Therefore, I expect that the AC verifier will only have a single trusted
> > AC issuer (or one for each set of attributes). Because of this, the AC
> > verifier (in the pull scenarios) should be able to pull all ACs from a
> > single repository or AC issuer (or one for each set of attributes).
> > There is no need for the PKC to include information about where to find
> > ACs. In the AC pull scenarios, the AC verifier will have this
> > information already configured. This model works in either an intranet
> > or an extranet case. The PKC may be issued by a third-party CA. But the
> > AC will always come from the single trusted AC issuer.
>
> That's my definition of a system that does not scale and have severe
> built-in security problems. I.e. multi-party update/access to a single repository
> containing fairly dynamic individual-specific information.
When a repository is used with the pull model, a single AC issuer writes
ACs to the repository (presumably with authentication and access
control). One or more AC verifiers fetch ACs from the repository (also
probably with authentication and access control). The issuer,
repository, and verifiers are contained within a single administrative
domain and access to the respository is restricted to authorized parties
(the issuer and the verifiers). The AC holders may be from other
domains, but they need not even know that ACs are being used. I don't
see the scaling issues and "severe built-in security problems" that you
referred to.
Of course, the AC verifiers could also fetch ACs directly from the AC
issuer (via LAAP or a similar protocol). This allows the AC issuer to
issue ACs on demand, which may provide better performance in some
circumstances.
> A single issuer is *not* a requirement so far as I can see. It that
> really is the case this scheme needs a *major* fix which I BTW see no
> chance of accomplishing.
As I previously noted, ac509prof specifically limits itself to the case
"where one authority issues all of the ACs for a particular set of
attributes." X.509 does not include such a limit. So if this is a
problem (and it would be helpful if you would point out why you think it
is), it could certainly be remedied by removing this restriction from
ac509prof and returning to the less restricted X.509 model.
Frankly, I do not find it useful for you to claim you have found scaling
problems, security problems, or other problems if you cannot describe in
clear and unambiguous terms what those problems are. Vague
pronouncements such as the ones in your most recent notes are more often
the cause of scaling and security problems than a solution to them.
> Question from a directory "Newbe": Can interlinked directories
> administered by the "business parties" themselves, form a virtual
> single repository (and therefore single verifier configuration),
> supporting multiple AC issuers?
It is certainly possible to link multiple directories together to form a
single "virtual repository". In practice, this is often complicated by
firewalls and access control issues. Do you really want to publish your
employee list and even ACs to the world? But I'm not yet convinced that
it is necessary to support multiple AC issuers, especially in the AC
pull model.
In any case, this has little to do with Holder formats.
-Steve
Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08003 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 06:55:04 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id JAA16003; Thu, 9 Nov 2000 09:57:22 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 9 Nov 2000 09:57:22 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: Steve Hanna <steve.hanna@sun.com>
cc: Anders Rundgren <anders.rundgren@telia.com>, ietf-pkix@imc.org
Subject: Re: AC Scenarios - PULL model
In-Reply-To: <3A0AAE25.E1BCDAEA@sun.com>
Message-ID: <Pine.LNX.4.10.10011090943380.143-100000@marcy.adiron.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 9 Nov 2000, Steve Hanna wrote:
> Anders Rundgren wrote:
> > I think your exposition of Internet Protocols and ACs was very
> > interesting. However, I see some problems (maybe due to lack of
> > knowledge) with the PULL model in general:
> >
> > If we are talking Internet Protocols I guess we should try to decide
> > if we are addressing closed PKIs (or closed environments), or the
> > open net with many parties of different trustworthiness and
> > longevity.
> >
> > If we are in a closed ("trusted") environment, AC-like information
> > can be gathered by several means including directories. This is an
> > established way of doing things.
> >
> > Now, if we instead say that ACs using the PULL model and TLS should
> > be used for extranet access we face an AC repository "URL"
> > configuration (and access right) problem as AFAIK there is no
> > straight-forward way of finding this information in the PKC.
> > Particularly not if the AA is disjunct from the CA.
>
> ac509prof (section 5) says that "The AC issuer MUST be directly trusted
> as an AC issuer (by configuration or otherwise)." It also says (section
> 1.1) "This specification deals with the simple cases where one authority
> issues all of the ACs for a particular set of attributes."
>
> Therefore, I expect that the AC verifier will only have a single trusted
> AC issuer (or one for each set of attributes). Because of this, the AC
> verifier (in the pull scenarios) should be able to pull all ACs from a
> single repository or AC issuer (or one for each set of attributes).
> There is no need for the PKC to include information about where to find
> ACs. In the AC pull scenarios, the AC verifier will have this
> information already configured. This model works in either an intranet
> or an extranet case. The PKC may be issued by a third-party CA. But the
> AC will always come from the single trusted AC issuer.
> > Conclusion: Solving the AC-PKC binding issue(s) is just one part of
> > the AC puzzle.
>
> Well, that's certainly the case!
>
In the CORBA Security Case, an object reference is configured with a
specification of where and how the client is supposed to find the
authorization information (which can be an X.509 AC, or one of these XML
thinggys) the object will understand. It is an authorization token layer
acquisition service, which we call ATLAS. It is up to the client to
contact that service and acquire the AC's (or whatever) based on its
authentication to the ATLAS. Then the client can push the ACs to the
object during a CORBA request.
In the pull scenario, you don't really need AC's at all. All you need is a
answer from a trusted somebody about the subject. It could be your
babysitter has a kerberos connection to your mother, who said you can play
outside. (no AC signature verification needed). I.e. your mother doesn't
have to sign a note, she can just tell the babysitter when asked.
Cheers,
-Polar
> -Steve
>
-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:polar@adiron.com 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05917 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 06:41:50 -0800 (PST)
Received: from mega (t1o69p11.telia.com [62.20.144.11]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id PAA25841; Thu, 9 Nov 2000 15:48:45 +0100 (CET)
Message-ID: <00e401c04a5b$f92eb100$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Steve Hanna" <steve.hanna@sun.com>
Cc: <ietf-pkix@imc.org>
References: <3A09AEB7.D7F6E184@sun.com> <001501c04a21$4b33dc40$0201a8c0@vincent.se> <3A0AAE25.E1BCDAEA@sun.com>
Subject: Re: AC Scenarios - PULL model
Date: Thu, 9 Nov 2000 15:47:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA05922
Steve,
> ac509prof (section 5) says that "The AC issuer MUST be directly trusted
> as an AC issuer (by configuration or otherwise)." It also says (section
> 1.1) "This specification deals with the simple cases where one authority
> issues all of the ACs for a particular set of attributes."
>
> Therefore, I expect that the AC verifier will only have a single trusted
> AC issuer (or one for each set of attributes). Because of this, the AC
> verifier (in the pull scenarios) should be able to pull all ACs from a
> single repository or AC issuer (or one for each set of attributes).
> There is no need for the PKC to include information about where to find
> ACs. In the AC pull scenarios, the AC verifier will have this
> information already configured. This model works in either an intranet
> or an extranet case. The PKC may be issued by a third-party CA. But the
> AC will always come from the single trusted AC issuer.
That's my definition of a system that does not scale and have severe
built-in security problems. I.e. multi-party update/access to a single repository
containing fairly dynamic individual-specific information. A single issuer is
*not* a requirement so far as I can see. It that really is the case this scheme
needs a *major* fix which I BTW see no chance of accomplishing.
Question from a directory "Newbe": Can interlinked directories administered by
the "business parties" themselves, form a virtual single repository (and therefore
single verifier configuration), supporting multiple AC issuers?
Anders
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04019 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 06:09:53 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24766; Thu, 9 Nov 2000 06:16:51 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA03831; Thu, 9 Nov 2000 09:16:50 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id JAA26443; Thu, 9 Nov 2000 09:16:48 -0500 (EST)
Message-ID: <3A0AB152.980DC84E@sun.com>
Date: Thu, 09 Nov 2000 09:14:42 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: ietf-pkix@imc.org
Subject: Re: AC Scenarios - PUSH model
References: <3A09AEB7.D7F6E184@sun.com> <001a01c04a27$9bb14580$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote:
> I would like to particularly discuss TLS PUSH as it *theoretically*
> at least could be of major interest in e-business.
>
> > C) TLS push
> >
> > Client sends ACs to server (probably requires modifications to the
> > TLS handshake). Server uses ACs to make authorization decisions.
>
> This is the $1000 000 question: Will this really happen? Will you
> (SUN) start to push this in the TLS-group? Because if you (and the
> others) don't, ACs will be left in a pretty miserable shape. Sort of
> "nowhere to go" -:(
I have no specific plans to push (or pull ;-) any particular model for
using ACs at this time. In fact, I noted my concerns with the TLS push
model at the end of my note. Why do you think that if TLS push is not
used, ACs will be in "pretty miserable shape"? What about the other
scenarios?
> > Client authentication using PKCs will probably be most common here,
> > but the client may also authenticate using a username and password
> > (after authenticating the server), one-time password, Kerberos, or
> > another technique.
>
> Modifying TLS to carry ACs but not requiring a (cryptograhically linked) PKC is probably
> a bad idea. If you really have been able to get an AC (on your hard-disk, in a smart-card or
> in your mobile phone), you should be equipped with PKCs as well.
I also am not thrilled with pushing ACs that are not linked to a PKC (or
at least a PK). I was simply trying to enumerate the possible scenarios
to determine the implications for holder formats.
> A question that comes to my mind is whether this scheme offers *any* advantages over
> the scheme suggested by Bob J in terms of distribution of certificates? Bob's scheme
> does *not* require changes in TLS. Although I am personally not very thrilled [working
> on a competing solution :-)], by the following idea, multiple client PKCs (containing
> different AC-like data and issued by possible different issuers) could share a common key-pair.
> By doing that a client can securely download additional "PKC-AC"s when needed from an
> existing trusted PKC.
Putting attributes in a PKC mixes short-lived bindings with long-lived
ones, reducing the likely validity of the PKC. And many organizations
want to manage authorization separately from authentication. I do not
mean that attributes should NEVER be put in PKCs, but there are
certainly some strong arguments against doing so. And there is little
benefit in the pull scenarios.
-Steve
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA03219 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 05:56:21 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19317; Thu, 9 Nov 2000 06:03:18 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA01656; Thu, 9 Nov 2000 09:03:17 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id JAA25542; Thu, 9 Nov 2000 09:03:16 -0500 (EST)
Message-ID: <3A0AAE25.E1BCDAEA@sun.com>
Date: Thu, 09 Nov 2000 09:01:09 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: ietf-pkix@imc.org
Subject: Re: AC Scenarios - PULL model
References: <3A09AEB7.D7F6E184@sun.com> <001501c04a21$4b33dc40$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote:
> I think your exposition of Internet Protocols and ACs was very
> interesting. However, I see some problems (maybe due to lack of
> knowledge) with the PULL model in general:
>
> If we are talking Internet Protocols I guess we should try to decide
> if we are addressing closed PKIs (or closed environments), or the
> open net with many parties of different trustworthiness and
> longevity.
>
> If we are in a closed ("trusted") environment, AC-like information
> can be gathered by several means including directories. This is an
> established way of doing things.
>
> Now, if we instead say that ACs using the PULL model and TLS should
> be used for extranet access we face an AC repository "URL"
> configuration (and access right) problem as AFAIK there is no
> straight-forward way of finding this information in the PKC.
> Particularly not if the AA is disjunct from the CA.
ac509prof (section 5) says that "The AC issuer MUST be directly trusted
as an AC issuer (by configuration or otherwise)." It also says (section
1.1) "This specification deals with the simple cases where one authority
issues all of the ACs for a particular set of attributes."
Therefore, I expect that the AC verifier will only have a single trusted
AC issuer (or one for each set of attributes). Because of this, the AC
verifier (in the pull scenarios) should be able to pull all ACs from a
single repository or AC issuer (or one for each set of attributes).
There is no need for the PKC to include information about where to find
ACs. In the AC pull scenarios, the AC verifier will have this
information already configured. This model works in either an intranet
or an extranet case. The PKC may be issued by a third-party CA. But the
AC will always come from the single trusted AC issuer.
> Conclusion: Solving the AC-PKC binding issue(s) is just one part of
> the AC puzzle.
Well, that's certainly the case!
-Steve
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA05241 for <ietf-pkix@imc.org>; Thu, 9 Nov 2000 00:27:01 -0800 (PST)
Received: from mega (t2o69p94.telia.com [62.20.144.214]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA17808; Thu, 9 Nov 2000 09:33:55 +0100 (CET)
Message-ID: <001a01c04a27$9bb14580$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Steve Hanna" <steve.hanna@sun.com>, <ietf-pkix@imc.org>
References: <3A09AEB7.D7F6E184@sun.com>
Subject: AC Scenarios - PUSH model
Date: Thu, 9 Nov 2000 09:32:33 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA05244
Steve,
I would like to particularly discuss TLS PUSH as it *theoretically* at least could
be of major interest in e-business.
> C) TLS push
>
> Client sends ACs to server (probably requires modifications to the
> TLS handshake). Server uses ACs to make authorization decisions.
This is the $1000 000 question: Will this really happen? Will you (SUN) start to
push this in the TLS-group? Because if you (and the others) don't, ACs will be left in a pretty
miserable shape. Sort of "nowhere to go" -:(
> Client authentication using PKCs will probably be most common here,
> but the client may also authenticate using a username and password
> (after authenticating the server), one-time password, Kerberos, or
> another technique.
Modifying TLS to carry ACs but not requiring a (cryptograhically linked) PKC is probably
a bad idea. If you really have been able to get an AC (on your hard-disk, in a smart-card or
in your mobile phone), you should be equipped with PKCs as well.
A question that comes to my mind is whether this scheme offers *any* advantages over
the scheme suggested by Bob J in terms of distribution of certificates? Bob's scheme
does *not* require changes in TLS. Although I am personally not very thrilled [working
on a competing solution :-)], by the following idea, multiple client PKCs (containing
different AC-like data and issued by possible different issuers) could share a common key-pair.
By doing that a client can securely download additional "PKC-AC"s when needed from an
existing trusted PKC.
Regards
Anders R
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA29451 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 23:41:48 -0800 (PST)
Received: from mega (t6o69p37.telia.com [213.64.110.157]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id IAA16816; Thu, 9 Nov 2000 08:48:43 +0100 (CET)
Message-ID: <001501c04a21$4b33dc40$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Steve Hanna" <steve.hanna@sun.com>, <ietf-pkix@imc.org>
References: <3A09AEB7.D7F6E184@sun.com>
Subject: AC Scenarios - PULL model
Date: Thu, 9 Nov 2000 08:47:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA29454
Steve,
> I promised to think more about which Holder format makes the most sense
> when an ODI with PK hash is included (formats 4, 6, 8, or 10).
>
> This got me to thinking about how ACs are going to be used with Internet
> protocols. In particular, I was wondering when it will be important to
> include hints (entityName and/or baseCertificateID) with an
> objectDigestInfo. I decided to describe and analyze all of the important
> circumstances under which ACs would be used with existing Internet
> protocols (since that is our primary area of concern). Here is the list
> of scenarios that I came up with:
> I'd appreciate feedback from others on these scenarios.
I think your exposition of Internet Protocols and ACs was very interesting.
However, I see some problems (maybe due to lack of knowledge) with
the PULL model in general:
If we are talking Internet Protocols I guess we should try to decide if
we are addressing closed PKIs (or closed environments), or the open net
with many parties of different trustworthiness and longevity.
If we are in a closed ("trusted") environment, AC-like information can be gathered by several
means including directories. This is an established way of doing things.
Now, if we instead say that ACs using the PULL model and TLS should be used
for extranet access we face an AC repository "URL" configuration (and access right)
problem as AFAIK there is no straight-forward way of finding this information in the PKC.
Particularly not if the AA is disjunct from the CA.
Conclusion: Solving the AC-PKC binding issue(s) is just one part of the AC puzzle.
Regards
Anders R
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20796 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 11:46:35 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18786 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 11:53:27 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA07825 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 14:53:26 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA15289 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 14:53:25 -0500 (EST)
Message-ID: <3A09AEB7.D7F6E184@sun.com>
Date: Wed, 08 Nov 2000 14:51:19 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: AC Scenarios
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I promised to think more about which Holder format makes the most sense
when an ODI with PK hash is included (formats 4, 6, 8, or 10).
This got me to thinking about how ACs are going to be used with Internet
protocols. In particular, I was wondering when it will be important to
include hints (entityName and/or baseCertificateID) with an
objectDigestInfo. I decided to describe and analyze all of the important
circumstances under which ACs would be used with existing Internet
protocols (since that is our primary area of concern). Here is the list
of scenarios that I came up with:
A) S/MIME push
Sender includes with a signed email message, in addition to the
normal PKCs, ACs vouching for certain attributes of the sender
(clearance, for instance). Receiver displays these attributes or
uses them to decide whether sender is authorized to receive
classified information or to classify information, etc. This
probably requires long-lived ACs. Otherwise, they may expire before
the receiver needs them.
B) S/MIME pull
Sender includes PKCs with a signed email message. Receiver pulls
ACs from a repository or AC issuer. Receiver displays these
attributes or uses them to decide whether sender is authorized to
receive classified information or to classify information, etc.
C) TLS push
Client sends ACs to server (probably requires modifications to the
TLS handshake). Server uses ACs to make authorization decisions.
Server could also send ACs to client, but that seems less likely.
Client authentication using PKCs will probably be most common here,
but the client may also authenticate using a username and password
(after authenticating the server), one-time password, Kerberos, or
another technique.
D) TLS pull
Client and server perform a normal TLS handshake without ACs. Server
pulls ACs from a repository or AC issuer and uses them to make
authorization decisions.
Client authentication using PKCs will probably be most common here,
but the client may also authenticate using a username and password
(after authenticating the server), one-time password, Kerberos, or
another technique.
E) IPsec push
One IPsec peer delivers ACs during phase 1 of IKE negotiation. The
other peer uses the ACs to make authorization decisions (or for
other purposes).
F) IPsec pull
An IPsec peer pulls ACs from a repository or AC issuer and uses
them to make authorization decisions (or for other purposes).
Here's my analysis of whether hints are needed with ODI holder formats
in each of these scenarios:
With scenario A (S/MIME push), PKCs are sent along with the ACs. The AC
verifier should not need to search for PKCs. If it does (for instance,
if the supplied PKCs don't match any of its trust anchors), it already
has lots of hints from the supplied PKCs (entityName, issuerName, etc.).
With scenario B (S/MIME pull), PKCs are sent with the message. As with
scenario A, the AC verifier will not need hints from the AC if it wants
to find replacements for the supplied PKCs.
With scenarios C and D (TLS push and pull), if the client authenticates
using PKCs, then (as with scenarios A and B) the ACs need not contain
hints. If the client does not authenticate using PKCs, then the AC will
need to be in format 2 (entityName only). Otherwise, the server will not
be able to associate it with the client identity. So this case has no
bearing on whether hints should be included with ODI formats.
With scenario E (IPsec push), the IPsec peer may or may not include PKCs
with the ACs. If PKCs are included, then no hints are needed. I
seriously doubt whether it's a good idea to include ACs without PKCs.
But if this is done, the ACs can use format 2 with the entityName
matching the IKE identification payload. Or the ACs can use an ODI with
a PK hash, where the hash matches the public key used to authenticate
the phase 1 exchange. If the ACs use an ODI with a PKC hash, I would
expect the PKC to be included with the ACs. So I don't think there's any
need for hints in the ODI formats with this scenario.
With scenario F (IPsec pull), the IPsec peer must supply enough
information so that the other party can identify and authenticate it
(identification and perhaps certificate payloads). This information can
(and probably should) be used to tie into the AC holder field. If the AC
uses format 2, this should match the identification (or one of the
subjectAltNames in a recognized PKC that matches the identification). If
the AC uses an ODI with a PK hash, the hash should match the public key
used to authenticate the phase 1 exchange. If the AC uses an ODI with a
PKC hash, the PKC can be found using the information contained in the
identification and certificate payloads.
I conclude that none of these scenarios require hints in an ODI holder
format. Does anyone disagree? Are there any other scenarios that we
should be considering? If not, perhaps we should recommend the use of
formats 2, 4, and 5.
The only other argument I have for including the hints is that they
might be useful when debugging or using auxiliary tools (to answer the
question "whose AC is this, anyway?"). But that's sort of weak. So I'm
inclined to say we should recommend formats 2, 4, and 5.
-Steve
P.S. I hope that others find this list of scenarios to be useful. I
certainly did. Personally, I find scenario D the most compelling one in
the short term. It can be deployed quickly, without any changes to TLS
or client software. The server can pull the ACs from a repository using
LDAP or HTTP. But this requires the AC issuer to keep the repository
populated. A better solution would be to use LAAP or something similar.
What ever happened to LAAP?
The S/MIME scenarios are not compelling to me, because I don't need to
worry about multi-level security. But for those who do, I expect that
those scenarios are important. Are there other compelling arguments for
the use of ACs with S/MIME?
The IPsec scenarios seem a bit distant, given that IPsec implementations
have only recently started to support PKCs. But we should certainly
consider them now.
The TLS push scenario will require protocol changes. And TLS client
authentication has been slow to deploy. And I doubt that this would work
well with short-lived ACs, since most TLS clients are not prepared to
spend a lot of time gathering ACs (especially since this may slow things
down or require user interaction). However, it might be useful in the
future.
I'd appreciate feedback from others on these scenarios.
Received: from junker.ms.inka.de (clxxxviii.yapay.inka.de [212.227.15.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20201 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 11:31:35 -0800 (PST)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 7C6F56832F for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 08:27:50 +0100 (CET)
Sender: michael@ms.inka.de
Message-ID: <3A090075.A968B988@stroeder.com>
Date: Wed, 08 Nov 2000 08:27:49 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <michael@stroeder.com>
Organization: stroeder.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Extended Key Usage and path validation
References: <05256990.007AF4B6.00@montreal1.yul.sita.int> <3A0899AD.6080702@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Terry Hayes wrote:
>
> Patrick.Patterson@sita.int <mailto:Patrick.Patterson@sita.int> wrote:
>
> > It's my reading of
> > the various standards that the Certificate Policy field should contain the OID
> > for the Certificate Policy under which that particular Certificate was issued -
> > and within that document, there would be the application limitation as specified
> > in section 1.4 of the Certificate Policy RFC.
>
> This seems to be the dominant interpretation of the Certificate Policies
> extension. However, as I said before, this does not provide a standard
> OID value that can built into mass-market applications and used to check
> the intended use.
Yes.
> Maybe what is needed is a very basic Certificate Policy document with a
> corresponding OID, that spells out the (small number) of requirements
> for issuing highly interoperable SSL or S/MIME certificates.
No. This would be messing with policies.
Ciao, Michael.
Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA06161 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 07:33:46 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 07050503; Wed, 8 Nov 2000 10:40:37 -0500 (EST)
Sender: rsalz
Message-ID: <3A09754D.4A027C19@caveosystems.com>
Date: Wed, 08 Nov 2000 10:46:21 -0500
From: Rich Salz <rsalz@caveosystems.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: phil.griffin@asn-1.com
CC: ietf-pkix@imc.org
Subject: Re: X509 ACs - Too late, too little
References: <200011081332.IAA32351@os390.caveosystems.com> <037e01c04993$1c379a00$0201a8c0@vincent.se> <3A097264.C912D8EF@asn-1.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
> Will the base W3C document be published as XML?
Looking at http://www.w3.org/TR/REC-xml which is the XML recommendation,
they seem to be trying to publish simultaneously in XML HTML XHTML and
PDF. I am not sure which is definitive, nor what they'd do if errors
occured between formats.
/r$
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05170 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 07:30:14 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G3P00101Q1WRN@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 8 Nov 2000 07:37:08 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G3P001EAQ1W0Q@ext-mail.valicert.com>; Wed, 08 Nov 2000 07:37:08 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <W2TWTYVR>; Wed, 08 Nov 2000 07:35:21 -0800
Content-return: allowed
Date: Wed, 08 Nov 2000 07:35:20 -0800
From: Frank Balluffi <frankb@valicert.com>
Subject: RE: Extended Key Usage and path validation
To: Frank Balluffi <frankb@valicert.com>, "'thayes@netscape.com'" <thayes@netscape.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E1365A7@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Note that the following is a very different story:
Issuer Subject Policy Identifiers
------ ------- ------------------
CA 1 CA 2 id-smime
Frank
> -----Original Message-----
> From: Frank Balluffi [mailto:frankb@valicert.com]
> Sent: Wednesday, November 08, 2000 10:21 AM
> To: 'thayes@netscape.com'
> Cc: 'ietf-pkix@imc.org'
> Subject: Re: Extended Key Usage and path validation
>
>
> Terry Hayes said:
>
> > In fact, I probably could be convinced that Certificate
> > Policies is the correct way of checking the validity of a
> > path for a particular purpose.
>
> Using certificate policies makes a lot of sense, but note that the CA
> issuing the end-entity certificate still has some flexibility
> over what
> policy identifiers are included in the end-entity certificate. In the
> following example (which I believe to be legal), CA 1 asserts
> nothing about
> signing S/MIME messages:
>
> Issuer Subject Policy Identifiers
> ------ ------- ------------------
> CA 1 CA 2 id-foo, id-goo
> CA 2 CA 3 id-goo, id-hoo
> CA 3 Alice id-goo, id-smime
>
> In the above example, the most superior certificate is not
> self signed.
>
> Frank
>
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04177 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 07:23:48 -0800 (PST)
Received: from asn-1.com (user-2ivf55p.dialup.mindspring.com [165.247.148.185]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA15050 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 10:30:41 -0500 (EST)
Message-ID: <3A097264.C912D8EF@asn-1.com>
Date: Wed, 08 Nov 2000 10:33:56 -0500
From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
Reply-To: phil.griffin@asn-1.com
Organization: Griffin Consulting
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: X509 ACs - Too late, too little
References: <200011081332.IAA32351@os390.caveosystems.com> <037e01c04993$1c379a00$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders Rundgren wrote:
>
> Rick,
>
> > With any luck, the base document is XML which can easily be translated
> > to HTML and IETF-RFC. :)
>
> I don't want to waste too much PKIX-bamdwidth on this issue as I understand
> it is rather "sensitive", but the statement above more or less dictates documents
> without pictures of any complexity. I.e. long-term I see some problems with the
> IETF-RFC format. The more complex thing gets, the worse it will be.
Your response still begs the question. Will
the base W3C document be published as XML?
Phil
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02226 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 07:15:43 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G3P00101PDKPT@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 8 Nov 2000 07:22:32 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G3P001CKPDK0Q@ext-mail.valicert.com>; Wed, 08 Nov 2000 07:22:32 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <W2TWTY4P>; Wed, 08 Nov 2000 07:20:45 -0800
Content-return: allowed
Date: Wed, 08 Nov 2000 07:20:44 -0800
From: Frank Balluffi <frankb@valicert.com>
Subject: Re: Extended Key Usage and path validation
To: "'thayes@netscape.com'" <thayes@netscape.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E1365A4@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Terry Hayes said:
> In fact, I probably could be convinced that Certificate
> Policies is the correct way of checking the validity of a
> path for a particular purpose.
Using certificate policies makes a lot of sense, but note that the CA
issuing the end-entity certificate still has some flexibility over what
policy identifiers are included in the end-entity certificate. In the
following example (which I believe to be legal), CA 1 asserts nothing about
signing S/MIME messages:
Issuer Subject Policy Identifiers
------ ------- ------------------
CA 1 CA 2 id-foo, id-goo
CA 2 CA 3 id-goo, id-hoo
CA 3 Alice id-goo, id-smime
In the above example, the most superior certificate is not self signed.
Frank
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29768 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 06:44:02 -0800 (PST)
Received: from mega (t5o69p10.telia.com [213.64.110.10]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id PAA17903; Wed, 8 Nov 2000 15:50:55 +0100 (CET)
Message-ID: <037e01c04993$1c379a00$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: <rsalz@CaveoSystems.com>
Cc: <ietf-pkix@imc.org>
References: <200011081332.IAA32351@os390.caveosystems.com>
Subject: Re: X509 ACs - Too late, too little
Date: Wed, 8 Nov 2000 15:49:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA29771
Rick,
> With any luck, the base document is XML which can easily be translated
> to HTML and IETF-RFC. :)
I don't want to waste too much PKIX-bamdwidth on this issue as I understand
it is rather "sensitive", but the statement above more or less dictates documents
without pictures of any complexity. I.e. long-term I see some problems with the
IETF-RFC format. The more complex thing gets, the worse it will be.
> Joint publication happens all the time. I am much less worried about incon-
> sistencies between the IETF and W3C versions, than I am about inconsistencies
> internal to the document itself.
BTW, joint publication would be greatly simplified if the parties put their marks in the very
same document instead of doing their own versions.
Then by allowing a slightly more advanced way of describing things than offered
by plain-text you *may* even limit some problems with draft interpretation itself.
I have yet to see any really valid arguments (except for the absolute need for 7-bit ASCII
plain-text and "politics") for having TWO documents.
And in contrast to the AC-draft, there is a whole industry waiting for XML-DSIG!
/Anders
Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA24625 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 05:19:59 -0800 (PST)
From: rsalz@CaveoSystems.com
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 07088514; Wed, 8 Nov 2000 08:26:38 -0500 (EST)
Received: (from rsalz@localhost) by os390.caveosystems.com (8.9.3/8.9.3) id IAA32351; Wed, 8 Nov 2000 08:32:21 -0500
Date: Wed, 8 Nov 2000 08:32:21 -0500
Message-Id: <200011081332.IAA32351@os390.caveosystems.com>
To: anders.rundgren@telia.com
Subject: Re: X509 ACs - Too late, too little
Cc: ietf-pkix@imc.org
X-Loop-Detect: 1
No, it's really a joint effort, with folks from both organizations
participating. At the risk of alienating others, for example, let
me point out Mr. Solo's prominent participation in both XML DSIG
and PKIX. Other recent participants (notable to me) include extensive
commentary and example Gindin of IBM and Merlin from baltimore.ie.
> I understand that IETF will convert the relatively =
> nice W3C HTML document into an ugly 7-bit ASCII RFC.
With any luck, the base document is XML which can easily be translated
to HTML and IETF-RFC. :)
>If the documents are (information-wise) identical,
>one is redundant and if they differ there is a potential
>interoperability problem in the works.
Joint publication happens all the time. I am much less worried about incon-
sistencies between the IETF and W3C versions, than I am about inconsistencies
internal to the document itself.
/r$
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22654 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 04:18:29 -0800 (PST)
Received: from mega (t4o69p3.telia.com [62.20.145.123]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id NAA01031; Wed, 8 Nov 2000 13:25:15 +0100 (CET)
Message-ID: <034901c0497e$c3323b90$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: <rsalz@CaveoSystems.com>, <mzolotarev@baltimore.com>
Cc: <ietf-pkix@imc.org>
References: <200011081128.GAA32194@os390.caveosystems.com>
Subject: Re: X509 ACs - Too late, too little
Date: Wed, 8 Nov 2000 13:23:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA22655
Rich,
> Perhaps you missed the fact that XML DSIG is a joint (one of several)
> IETF/W3C effort?
I am aware of this. I understand that IETF will convert the relatively nice W3C HTML document
into an ugly 7-bit ASCII RFC. Just wondering who is going to read the latter when
the former contains all you need? If the documents are (information-wise) identical,
one is redundant and if they differ there is a potential interoperability problem in the works.
That IETF *competence* may be called for is another thing which I fully understand.
Maybe I have lately been too much into product strategies, business priorities, and dead-lines to
fully see the benefits of TWO standards? Or two standard organizations doing the same
thing. That could BTW be applied to ISO/X500 and PKIX as well. Time to migrate maybe?
Particularly as PKIX nowadays is closer to the "market" and the developer community.
Pardon for bringing all this c**p up on the table. I don't expect any changes in this area
as "standards" are very close to "politics"...
Anders
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18548 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 03:34:20 -0800 (PST)
Received: from certplus.com ([192.168.212.171]) by certplus.com (8.8.7/8.8.7) with ESMTP id MAA05498; Wed, 8 Nov 2000 12:45:36 +0100
Message-ID: <3A093B6B.B90BC15D@certplus.com>
Date: Wed, 08 Nov 2000 12:39:23 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Terry Hayes <thayes@netscape.com>, ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Extended Key Usage and path validation
References: <613B3C619C9AD4118C4E00B0D03E7C3E136578@exchange.valicert.com> <v04220803b628fb6e83f8@[171.78.30.108]> <3A068CCF.56574B9F@certplus.com> <3A085858.1070100@netscape.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Terry Hayes wrote:
> the extension is checked at all points in the path. Except for the
> trusted anchor all CA certificates in the path must have the EKU value
> corresponding with the current usage.
> (Actually, CA certificates without and EKU extension are
> "grandfathered" for SSL and S/MIME, but not object signing).
That's not the result of my tests with the current Netscape Navigator
(4.75) and the object signing tools (signtool 1.3).
According to this tests, CA certificates without EKU and NKU extension
are "grandfathered" for object signing too when checking the correct
box.
For the object signing tool, the CA that delivers the signers
certificate must be authorized for object signing, but the check box for
that is available even when there is neither EKU and no NKU in the CA
certificate.
For the navigator, one of the CA in the trust chain must be authorized
for object signing (the box has to be checked).
I've been testing with a signer certificate, an object signing CA, a CA
that signs this CA, and another root CA above all that, therefore three
levels of CAs.
It's impossible to authorize a CA for object signing when the NKU/EKU
are present and don't have the correct usage.
Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA17020 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 03:16:04 -0800 (PST)
From: rsalz@CaveoSystems.com
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 04895256; Wed, 8 Nov 2000 06:22:57 -0500 (EST)
Received: (from rsalz@localhost) by os390.caveosystems.com (8.9.3/8.9.3) id GAA32194; Wed, 8 Nov 2000 06:28:39 -0500
Date: Wed, 8 Nov 2000 06:28:39 -0500
Message-Id: <200011081128.GAA32194@os390.caveosystems.com>
To: anders.rundgren@telia.com, mzolotarev@baltimore.com
Subject: Re: X509 ACs - Too late, too little
Cc: ietf-pkix@imc.org
X-Loop-Detect: 1
>the IETF prefers to wait until XML is "everywhere", the chance to actually
>do something on IETF's part becomes very slim.
Perhaps you missed the fact that XML DSIG is a joint (one of several)
IETF/W3C effort?
/r$
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA21928 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 23:42:01 -0800 (PST)
Received: from mega (t5o69p99.telia.com [213.64.110.99]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id IAA10946; Wed, 8 Nov 2000 08:48:49 +0100 (CET)
Message-ID: <002101c04958$24c23170$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Michael Zolotarev" <mzolotarev@baltimore.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <D44EACB40164D311BEF00090274EDCCACF84FD@SYDNEYMAIL1>
Subject: Re: X509 ACs - Too late, too little
Date: Wed, 8 Nov 2000 08:47:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA21930
Hi Michael,
> It is just an encoding, not the principle of AC you are questioning now,
> aren't you?
That's right. *This* time I only addressed the format issue :-)
> IETF AC profile is a *profile*. Which means it *profiles*, or specialises on
> broad definition of AC by ISO in X509. ISO uses ASN1 encoding. So does the
> IETF's profile. Departing from ISO conventions, for whatever reason,
> wouldn't be prudent, at least at that stage. When, and if, XML-based PKI
> takes off and cheered by the industry, there should be enough influence to
> have ISO/IETF reevaluate their approach to encoding.
Departing from ISO conventions for a thing that is new, not established, and
even not recognized as useful by all parties does IMO not seem too unreasonable. If
the IETF prefers to wait until XML is "everywhere", the chance to actually
do something on IETF's part becomes very slim. It seems that PKI + XML are
quickly becoming "hot" which may call for other measures than when PKI was just
something folks from academia loved to talk about.
> XACL is a language that Alphaworks trust establishment solution uses to
> describe their transitive recognition and verification rules. It has nothing
> to do with AC, if I recall it right. Guys from AlphaWorks, Yosi, where are
> you?
Oops! You are correct. I read the paper briefly and in too much haste!
(Some parts may apply though as there are ways to express roles etc. that could
fit an XML-AC)
Anders
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02586; Tue, 7 Nov 2000 16:44:28 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0501047ab62e52bb84f2@[165.227.249.17]>
In-Reply-To: <006e01c048a7$5d3497c0$0201a8c0@vincent.se>
References: <006e01c048a7$5d3497c0$0201a8c0@vincent.se>
Date: Tue, 7 Nov 2000 16:51:19 -0800
To: "Anders Rundgren" <anders.rundgren@telia.com>, "PKIX-List" <ietf-pkix@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: X509 ACs - Too late, too little
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 11:42 AM +0100 11/7/00, Anders Rundgren wrote:
>XML-signatures are apparantly coming on strong.
For some value of "apparently". Please note that, even after the last
call, people are still reporting technical changes that need to be
made to the spec.
>W3C now says the draft is in an advanced state.
Yes, they have been saying that for quite some time.
>And IBM has kindly provided a reference implementation for public use at:
>
>http://www.alphaworks.ibm.com/tech/xmlsecuritysuite
>
>So why would anybody bother with ASN.1-based ACs?
This is a non-sequetor. XML signatures are signatures, they are not
formats for certificates. As you point out, the XML DIGSIG draft (it
is still not a standard) uses PKIX certificates.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01680 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 16:03:33 -0800 (PST)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id eA801nD10893 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 16:01:51 -0800 (PST)
Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G3OJ3H00.W09; Tue, 7 Nov 2000 16:09:17 -0800
Message-ID: <3A0899AD.6080702@netscape.com>
Date: Tue, 07 Nov 2000 16:09:17 -0800
From: thayes@netscape.com (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001106 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Patrick.Patterson@sita.int
CC: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Extended Key Usage and path validation
References: <05256990.007AF4B6.00@montreal1.yul.sita.int>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Patrick.Patterson@sita.int <mailto:Patrick.Patterson@sita.int> wrote:
>
> I'm not sure that I would concur with your willingness to assign a set of
> standard values to the Certificate Policy field - (I'm not in favour of the
> Netscape EKU Extension either, but that's another argument) - It's my reading of
> the various standards that the Certificate Policy field should contain the OID
> for the Certificate Policy under which that particular Certificate was issued -
> and within that document, there would be the application limitation as specified
> in section 1.4 of the Certificate Policy RFC.
This seems to be the dominant interpretation of the Certificate Policies
extension. However, as I said before, this does not provide a standard
OID value that can built into mass-market applications and used to check
the intended use. Using a different policy OID in each certificate
hierarchy would required too much configuration.
Maybe what is needed is a very basic Certificate Policy document with a
corresponding OID, that spells out the (small number) of requirements
for issuing highly interoperable SSL or S/MIME certificates. For
example, the policy for an SSL certificate would limit (allow?) its use
(in section 1.4) to SSL operations. It might also state that the CA
must ensure that correct values are provided for the dnsName option of
the SubjectAlternativeName so the the usual matching of identity with
URL can be performed securely.
A CA can put this global OID into the CertificatePolicies along with
OIDs for its own more specific or more constrained policies. The
extension can handle more than one OID.
> I know the issue here is that we need some technical way to assure that a given
> certificate isn't used for something that it was not intended for, but I'm not
> sure that either the current method or your proposed fix is the way it should
> go. Shouldn't this be something that an attribute certificate be used for, or am
> I completely off the mark with that?
I don't think attribute certs are the answer. They aren't deployed
widely yet, and aren't supported by some protocols. In addition, isn't
they subject to the same problem of determining whether the CA is
allowed to set attributes enabling SSL or S/MIME operations?
Terry Hayes
Netscape Communications Corp.
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01020 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 15:39:00 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA00435; Wed, 8 Nov 2000 09:53:10 +1100
Received: by SYDNEYMAIL1 with Internet Mail Service (5.5.2650.21) id <W1NNQGWF>; Wed, 8 Nov 2000 10:43:57 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCACF84FD@SYDNEYMAIL1>
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Anders Rundgren <anders.rundgren@telia.com>
Cc: PKIX-List <ietf-pkix@imc.org>
Subject: RE: X509 ACs - Too late, too little
Date: Wed, 8 Nov 2000 10:43:56 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Anders,
It is just an encoding, not the principle of AC you are questioning now,
aren't you?
IETF AC profile is a *profile*. Which means it *profiles*, or specialises on
broad definition of AC by ISO in X509. ISO uses ASN1 encoding. So does the
IETF's profile. Departing from ISO conventions, for whatever reason,
wouldn't be prudent, at least at that stage. When, and if, XML-based PKI
takes off and cheered by the industry, there should be enough influence to
have ISO/IETF reevaluate their approach to encoding.
XACL is a language that Alphaworks trust establishment solution uses to
describe their transitive recognition and verification rules. It has nothing
to do with AC, if I recall it right. Guys from AlphaWorks, Yosi, where are
you?
Michael
> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Wednesday, 8 November 2000 0:59
> To: Rich Salz
> Cc: PKIX-List
> Subject: Re: X509 ACs - Too late, too little
>
>
> Rich,
>
> > I'm confused. Why is an XML-based signature "competition"
> with an AC?
> > Isn't it more in "competition" with PKCS#7?
> > /r$
>
> This is correct. XML-sig is a replacement for PKCS #7.
>
> However, I see no problems in creating an AA-signed
> "attribute container" in
> XML based on the W3C/IETF draft in progress. That could
> functionally replace a X509 AC.
>
> Such a system would inherit the advantages of XML like the "schema",
> and the (very) likely broad acceptance in the commercial world.
>
> A better mousetrap IMO.
>
> BTW, when I downloaded the IBM AlphaWorks code I found
> something called
> XACL - XML Access Control Language
> so *maybe* there is some kind of XML AC out there already!!!
>
> /Anders
>
>
>
Received: from mx.sita.int (mx1.sita.int [57.250.224.237]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28808 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 14:17:48 -0800 (PST)
From: Patrick.Patterson@sita.int
Received: from montreal1.yul.sita.int (montreal1.yul.sita.int [57.4.233.253]) by mx.sita.int with SMTP id eA7MN7F11191; Tue, 7 Nov 2000 22:23:07 GMT
Received: by montreal1.yul.sita.int(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 05256990.007AF624 ; Tue, 7 Nov 2000 17:23:04 -0500
X-Lotus-FromDomain: SITA
To: thayes@netscape.com (Terry Hayes)
cc: ietf-pkix <ietf-pkix@imc.org>
Message-ID: <05256990.007AF4B6.00@montreal1.yul.sita.int>
Date: Tue, 7 Nov 2000 22:23:05 +0000
Subject: Re: Extended Key Usage and path validation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
First of all, I should probably introduce myself: I'm the lead PKI Architect for
the SITA/Equant Digital Certification Service, where I've been responsible for
most of the technical and policy implementation on issues surrounding our PKI
roll out.
Now to business:
Terry et al:
I'm not sure that I would concur with your willingness to assign a set of
standard values to the Certificate Policy field - (I'm not in favour of the
Netscape EKU Extension either, but that's another argument) - It's my reading of
the various standards that the Certificate Policy field should contain the OID
for the Certificate Policy under which that particular Certificate was issued -
and within that document, there would be the application limitation as specified
in section 1.4 of the Certificate Policy RFC.
I know the issue here is that we need some technical way to assure that a given
certificate isn't used for something that it was not intended for, but I'm not
sure that either the current method or your proposed fix is the way it should
go. Shouldn't this be something that an attribute certificate be used for, or am
I completely off the mark with that?
------
Patrick Patterson
PKI Architect, IPVAS CA
SITA/Equant JV.
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24865 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 12:12:08 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id JAA20108 for <ietf-pkix@imc.org>; Wed, 8 Nov 2000 09:18:48 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97362833724052>; Wed, 8 Nov 2000 09:18:57 (NZDT)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: ietf-pkix@imc.org
Subject: Re: Extended Key Usage and path validation
Sender: pgut001@cs.auckland.ac.nz
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 8 Nov 2000 09:18:57 (NZDT)
Message-ID: <97362833724052@kahu.cs.auckland.ac.nz>
thayes@netscape.com (Terry Hayes) writes:
>Since the processing of the EKU extension is intended to provide information
>on both the EE (can it participate in this PKI application) and the CA (can it
>issue the certificate), the extension is checked at all points in the path.
>Except for the trusted anchor all CA certificates in the path must have the
>EKU value corresponding with the current usage. (Actually, CA certificates
>without and EKU extension are "grandfathered" for SSL and S/MIME, but not
>object signing). The result is effectively the intersection of the EKU values
>in the path.
I used to do this as well, until someone complained that this was broken since
I was rejecting some otherwise valid certs as invalid. Reading RFC 2459, I had
to agree that it probably was broken (at least in terms of RFC 2459) since the
EKU would apply to the CA's key, not the keys in the certs it issues. I think
it's more logical to have it apply to certs it issues, but then you have the
problem that in a CA cert, KU applies to the CA's key and EKU applies to the
issued cert's keys. Son-of-2459 could do with some added clarification in this
area, although given the current ambiguity and the fact that there appear to be
implementations which have either intepretation, it may be a bit late. Looks
like the style guide needs an update in this area...
Peter.
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23129 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 11:24:10 -0800 (PST)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id eA7JN3D06347 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 11:23:04 -0800 (PST)
Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G3O66U01.UTL; Tue, 7 Nov 2000 11:30:30 -0800
Message-ID: <3A085858.1070100@netscape.com>
Date: Tue, 07 Nov 2000 11:30:32 -0800
From: thayes@netscape.com (Terry Hayes)
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001104 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
CC: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Extended Key Usage and path validation
References: <613B3C619C9AD4118C4E00B0D03E7C3E136578@exchange.valicert.com> <v04220803b628fb6e83f8@[171.78.30.108]> <3A068CCF.56574B9F@certplus.com>
Content-Type: multipart/alternative; boundary="------------000009000505050509030905"
--------------000009000505050509030905
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Netscape's processing of the EKU extension requires that every
certificate in the chain has a particular EKU value in some cases. The
EKU extension is being used as a replacement for an older
Netscape-defined extension called "Netscape Certificate Type". This
extension indicated the types of PKI applications that the certificate
could be used for, and for CAs indicated whether the CA was allowed to
issue certificates for that PKI application. The older extension
covered SSL (client and server), S/MIME and "object signing" (for secure
Java applications).
Since the processing of the EKU extension is intended to provide
information on both the EE (can it participate in this PKI application)
and the CA (can it issue the certificate), the extension is checked at
all points in the path. Except for the trusted anchor all CA
certificates in the path must have the EKU value corresponding with the
current usage. (Actually, CA certificates without and EKU extension are
"grandfathered" for SSL and S/MIME, but not object signing). The result
is effectively the intersection of the EKU values in the path.
That's the current implementation. I believe that IE does similar
processing. I do agree with Stephen Kent that this might be viewed as
conflicting with the key usage that applies to the CA itself. That is,
the presence of an EKU extension value for S/MIME in the CA certificate
might be interpreted as allowing the CA to use the key for signing
S/MIME messages, rather than indicating that it can issued S/MIME
certificates.
In fact, I probably could be convinced that Certificate Policies is the
correct way of checking the validity of a path for a particular
purpose. An application might require that a particular policy value is
present in a certificate path before S/MIME operations would be allowed
using that certificate. X.509 and the various PKIX RFCs already define
how to validate the policy extension.
The problem with using certificate policy values for this purpose is
that there is no standard policy OID that is defined to represent S/MIME
or SSL operations. In order to encourage wide interoperability of these
applications, the software must come with certain values preinstalled.
Most users don't have the understanding necessary or the desire to
configure their browser or messaging software with PKI configuration
data. If policy values are used to control this, a standard value must
be defined and used by all PKI deployments, to represent basic S/MIME or
SSL enablement.
We could probably "steal" the OID from the EKU definition, and use it in
the context of certificate policy. I don't see any problem with doing
this; it would cleanly separate the path validation parameters from the
intended end-use of the key.
Terry Hayes
Netscape Communications Corp.
Jean-Marc Desperrier wrote:
> Stephen Kent wrote:
>
>> The Netscape discussion for this extension makes little or no sense
>> to me, based on your description. As Frank notes, this is an
>> extension one expects to see in an EE cert, vs. a CA cert, so one
>> would not encounter multiple ones in validating a path. If I did use
>> this extension in a CA cert, given the semantics, it might well
>> conflict with an EE usage. Certainly the keyUasage bits for CA certs
>> and EE certs are distinct, so why would one expect a relationship of
>> the sort described for this extension.
>
>
> Thank you Stephen for this clear comment.
>
> I can now consider I have a definitive answer on that :-)
>
> In fact, what Netscape describes is the behaviour of Microsoft products
> today, not really it's own, as far as I understand.
>
--------------000009000505050509030905
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html><head></head><body>Netscape's processing of the EKU extension requires
that every certificate in the chain has a particular EKU value in some cases.
The EKU extension is being used as a replacement for an older Netscape-defined
extension called "Netscape Certificate Type". This extension indicated the
types of PKI applications that the certificate could be used for, and for
CAs indicated whether the CA was allowed to issue certificates for that PKI
application. The older extension covered SSL (client and server), S/MIME
and "object signing" (for secure Java applications).<br>
<br>
Since the processing of the EKU extension is intended to provide information
on both the EE (can it participate in this PKI application) and the CA (can
it issue the certificate), the extension is checked at all points in the
path. Except for the trusted anchor all CA certificates in the path must
have the EKU value corresponding with the current usage. (Actually, CA certificates
without and EKU extension are "grandfathered" for SSL and S/MIME, but not
object signing). The result is effectively the intersection of the EKU values
in the path.<br>
<br>
That's the current implementation. I believe that IE does similar processing.
I do agree with Stephen Kent that this might be viewed as conflicting with
the key usage that applies to the CA itself. That is, the presence of an
EKU extension value for S/MIME in the CA certificate might be interpreted
as allowing the CA to use the key for signing S/MIME messages, rather than
indicating that it can issued S/MIME certificates.<br>
<br>
In fact, I probably could be convinced that Certificate Policies is the correct
way of checking the validity of a path for a particular purpose. An application
might require that a particular policy value is present in a certificate
path before S/MIME operations would be allowed using that certificate. X.509
and the various PKIX RFCs already define how to validate the policy extension.<br>
<br>
The problem with using certificate policy values for this purpose is that
there is no standard policy OID that is defined to represent S/MIME or SSL
operations. In order to encourage wide interoperability of these applications,
the software must come with certain values preinstalled. Most users don't
have the understanding necessary or the desire to configure their browser
or messaging software with PKI configuration data. If policy values are
used to control this, a standard value must be defined and used by all PKI
deployments, to represent basic S/MIME or SSL enablement.<br>
<br>
We could probably "steal" the OID from the EKU definition, and use it in
the context of certificate policy. I don't see any problem with doing this;
it would cleanly separate the path validation parameters from the intended
end-use of the key.<br>
<br>
Terry Hayes<br>
Netscape Communications Corp.<br>
<br>
Jean-Marc Desperrier wrote:<br>
<blockquote type="cite" cite="mid:3A068CCF.56574B9F@certplus.com"><pre wrap="">Stephen Kent wrote:<br><br></pre>
<blockquote type="cite"><pre wrap="">The Netscape discussion for this extension makes little or no sense<br>to me, based on your description. As Frank notes, this is an<br>extension one expects to see in an EE cert, vs. a CA cert, so one<br>would not encounter multiple ones in validating a path. If I did use<br>this extension in a CA cert, given the semantics, it might well<br>conflict with an EE usage. Certainly the keyUasage bits for CA certs<br>and EE certs are distinct, so why would one expect a relationship of<br>the sort described for this extension.<br></pre></blockquote>
<pre wrap=""><!----><br>Thank you Stephen for this clear comment.<br><br>I can now consider I have a definitive answer on that :-)<br><br>In fact, what Netscape describes is the behaviour of Microsoft products<br>today, not really it's own, as far as I understand.<br><br></pre>
</blockquote>
<br>
</body></html>
--------------000009000505050509030905--
Received: from inkjetfills.com ([63.174.85.142]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19582 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 10:23:24 -0800 (PST)
Date: Tue, 7 Nov 2000 10:58:52 -0600
From: "Irma Garcia" <irmag@inkjetfills.com>
Message-ID: <B62D90EC.58E86F@[63.174.85.142]>
To: ietf-pkix@imc.org
Subject: ALBAAT Inkjet News v.19/EA-3/G-M
X-Mailer: eMerge 1.62
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
ALBAAT has become an expert in the ink jet cartridge remanufacturing
industry. We can manufacture over 65 inkjet cartridges with state of the
art equipment.
http://www.inkjetfills.com/free.html
Send us your empty cartridge, and we will gladlly recycle it for you and
save you money. Simply request one of our Free Ink Jet prepaid shipping
labels.
If for any reason you are not interested in using remanufactured
cartridgesS Please use our Free Ink Jet Recycling Kit, Just put all your
empties into the kit, seal it and Drop into the nearest mailbox. ALBAAT
will gladly donate $.50-$1.00 for your empty.
You are receiving this email because you are a past or current customer,
vendor , or have either inquired about or requested information from this
company. If you wish for us to remove you from our customer list, please
reply to this message to let us know and we will honor your request to
exclude you from further mailings.
Sincerely,
Irma A. Garcia
irmag@inkjetfills.com
Fx# 512-219-1198
ALBAAT INKJET FILLS
12129 North Highway 620 #540
Austin, Texas 78750
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02720 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 06:54:01 -0800 (PST)
Received: from mega (t2o69p99.telia.com [62.20.144.219]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id QAA15804; Tue, 7 Nov 2000 16:00:48 +0100 (CET)
Message-ID: <00de01c048cb$52e5b280$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Rich Salz" <rsalz@caveosystems.com>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <006e01c048a7$5d3497c0$0201a8c0@vincent.se> <3A08043C.216893B6@caveosystems.com>
Subject: Re: X509 ACs - Too late, too little
Date: Tue, 7 Nov 2000 15:59:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA02722
Rich,
> I'm confused. Why is an XML-based signature "competition" with an AC?
> Isn't it more in "competition" with PKCS#7?
> /r$
This is correct. XML-sig is a replacement for PKCS #7.
However, I see no problems in creating an AA-signed "attribute container" in
XML based on the W3C/IETF draft in progress. That could functionally replace a X509 AC.
Such a system would inherit the advantages of XML like the "schema",
and the (very) likely broad acceptance in the commercial world.
A better mousetrap IMO.
BTW, when I downloaded the IBM AlphaWorks code I found something called
XACL - XML Access Control Language
so *maybe* there is some kind of XML AC out there already!!!
/Anders
Received: from edelweb.fr ([212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29945 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 06:30:10 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA09331; Tue, 7 Nov 2000 15:36:58 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 7 Nov 2000 15:36:58 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA01394; Tue, 7 Nov 2000 15:36:56 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA04258; Tue, 7 Nov 2000 15:36:56 +0100 (MET)
Date: Tue, 7 Nov 2000 15:36:56 +0100 (MET)
Message-Id: <200011071436.PAA04258@emeriau.edelweb.fr>
To: Peter.Sylvester@EdelWeb.fr, Denis.Pinkas@bull.net
Subject: Re: TSP. Version 10, Removal of SIA Extension
Cc: ietf-pkix@imc.org
>
> An answer has been given to Michael on Mon, 23 Oct 2000 18:35:43 +0200 and
> is copied at the end of this message by ourself.
I have read Michael's message and my question was a reaction on your answer.
You have accepted done a slight modification of a well accepted feature
(AIA->SIA) and then you have realized that this blocks the text, as a simple
remedy you just remove everything.
I have proposed a way to keep the feature inside the current text
that does not block the tsp draft. This was seconded by Michael,
and I wondered why there was no reaction.
>
> > IMHO after some reasonable time no answer can be interpreted as
> > "I don't care, you are talking non-sense."
>
> Keep such interpretations out, ... as well as your flames.
You might consider to keep out your projections out of the discussion.
There is no flame, and it is not me who interpretes.
Peter
>
> Denis
>
> > From: Michael Zolotarev <mzolotarev@baltimore.com>
> > To: Peter Sylvester <Peter.Sylvester@edelweb.fr>, Denis.Pinkas@bull.net
> > Cc: ietf-pkix@imc.org
> > Subject: RE: TSP. Version 10, Removal of SIA Extension
> > Date: Tue, 24 Oct 2000 09:48:57 +1000
> >
> > I second the proposal.
> >
> > > -----Original Message-----
> > > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr]
> > > Sent: Tuesday, 24 October 2000 3:10
> > > To: mzolotarev@baltimore.com; Denis.Pinkas@bull.net
> > > Cc: ietf-pkix@imc.org
> > > Subject: Re: TSP. Version 10, Removal of SIA Extension
> > >
> > >
> > >
> > >
> > > A TS certificate contains the an access information was a feature in
> > > the text, having this removed may not easily allow to get it back
> > > in a next round.
> > >
> > > I would consider to include the complete definition of SIA in the
> > > TS text since it is not or not yet defined anywhere else, and
> > > maybe mention that it is expected that it will be removed later.
> > >
> > > In this way the feature is described and stable, and when
> > > as soon as part1 gets updated and the TS text gets moved from
> > > proposed to draft, one can remove it without having added
> > > or removed any functionality.
> > >
> > > > Michael,
> > > >
> > > > > Sounds like its time to get SIA back to TSS draft, Denis :)
> > > >
> > > > "son-of-RFC2459" has not yet passed WG last call, nor IESG
> > > last call.
> > > > Waiting for it would create a delay that could be estimated
> > > to be, at best,
> > > > about two months and thus would mean issuing the TSP RFC
> > > next year. :-(
> > > >
> > > > We now need this long-awaited RFC.
> > > >
> > > > Denis
> > > >
> > > > Note: I have just posted to the web editor an update
> > > (version 11) that
> > > > incorporates the changes that have been noticed (plus one,
> > > un-noticed in the
> > > > ASN1 module !)
> > >
> >
> > ----- End Included Message -----
>
Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA25398 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 05:22:44 -0800 (PST)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 04684512; Tue, 7 Nov 2000 08:29:17 -0500 (EST)
Received: from caveosystems.com (adsl-141-154-81-199.bellatlantic.net [141.154.81.199]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id IAA28396; Tue, 7 Nov 2000 08:34:56 -0500
Message-ID: <3A08043C.216893B6@caveosystems.com>
Date: Tue, 07 Nov 2000 08:31:40 -0500
From: Rich Salz <rsalz@caveosystems.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: PKIX-List <ietf-pkix@imc.org>
Subject: Re: X509 ACs - Too late, too little
References: <006e01c048a7$5d3497c0$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
I'm confused. Why is an XML-based signature "competition" with an AC?
Isn't it more in "competition" with PKCS#7?
/r$
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA24837 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 05:16:34 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA14510; Tue, 7 Nov 2000 14:28:41 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA25966; Tue, 7 Nov 2000 14:22:13 +0100
Message-ID: <3A080206.BDC214C4@bull.net>
Date: Tue, 07 Nov 2000 14:22:14 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
CC: ietf-pkix@imc.org
Subject: Re: TSP. Version 10, Removal of SIA Extension
References: <200011071224.NAA04210@emeriau.edelweb.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter,
> The following two mails had been addressed to the editor of the
> time stamping draft. This doesn't mean that other couldn't comment.
>
> And it would be nice to read an answer from the editor,
An answer has been given to Michael on Mon, 23 Oct 2000 18:35:43 +0200 and
is copied at the end of this message by ourself.
> IMHO after some reasonable time no answer can be interpreted as
> "I don't care, you are talking non-sense."
Keep such interpretations out, ... as well as your flames.
Denis
> From: Michael Zolotarev <mzolotarev@baltimore.com>
> To: Peter Sylvester <Peter.Sylvester@edelweb.fr>, Denis.Pinkas@bull.net
> Cc: ietf-pkix@imc.org
> Subject: RE: TSP. Version 10, Removal of SIA Extension
> Date: Tue, 24 Oct 2000 09:48:57 +1000
>
> I second the proposal.
>
> > -----Original Message-----
> > From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr]
> > Sent: Tuesday, 24 October 2000 3:10
> > To: mzolotarev@baltimore.com; Denis.Pinkas@bull.net
> > Cc: ietf-pkix@imc.org
> > Subject: Re: TSP. Version 10, Removal of SIA Extension
> >
> >
> >
> >
> > A TS certificate contains the an access information was a feature in
> > the text, having this removed may not easily allow to get it back
> > in a next round.
> >
> > I would consider to include the complete definition of SIA in the
> > TS text since it is not or not yet defined anywhere else, and
> > maybe mention that it is expected that it will be removed later.
> >
> > In this way the feature is described and stable, and when
> > as soon as part1 gets updated and the TS text gets moved from
> > proposed to draft, one can remove it without having added
> > or removed any functionality.
> >
> > > Michael,
> > >
> > > > Sounds like its time to get SIA back to TSS draft, Denis :)
> > >
> > > "son-of-RFC2459" has not yet passed WG last call, nor IESG
> > last call.
> > > Waiting for it would create a delay that could be estimated
> > to be, at best,
> > > about two months and thus would mean issuing the TSP RFC
> > next year. :-(
> > >
> > > We now need this long-awaited RFC.
> > >
> > > Denis
> > >
> > > Note: I have just posted to the web editor an update
> > (version 11) that
> > > incorporates the changes that have been noticed (plus one,
> > un-noticed in the
> > > ASN1 module !)
> >
>
> ----- End Included Message -----
Received: from edelweb.fr ([212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22223 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 04:17:43 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA08565 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 13:24:32 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 7 Nov 2000 13:24:32 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA00976 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 13:24:31 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA04210 for ietf-pkix@imc.org; Tue, 7 Nov 2000 13:24:31 +0100 (MET)
Date: Tue, 7 Nov 2000 13:24:31 +0100 (MET)
Message-Id: <200011071224.NAA04210@emeriau.edelweb.fr>
To: ietf-pkix@imc.org
Subject: RE: TSP. Version 10, Removal of SIA Extension
The following two mails had been addressed to the editor of the
time stamping draft. This doesn't mean that other couldn't comment.
And it would be nice to read an answer from the editor,
IMHO after some reasonable time no answer can be interpreted as
"I don't care, you are talking non-sense."
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: Peter Sylvester <Peter.Sylvester@edelweb.fr>, Denis.Pinkas@bull.net
Cc: ietf-pkix@imc.org
Subject: RE: TSP. Version 10, Removal of SIA Extension
Date: Tue, 24 Oct 2000 09:48:57 +1000
I second the proposal.
> -----Original Message-----
> From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr]
> Sent: Tuesday, 24 October 2000 3:10
> To: mzolotarev@baltimore.com; Denis.Pinkas@bull.net
> Cc: ietf-pkix@imc.org
> Subject: Re: TSP. Version 10, Removal of SIA Extension
>
>
>
>
> A TS certificate contains the an access information was a feature in
> the text, having this removed may not easily allow to get it back
> in a next round.
>
> I would consider to include the complete definition of SIA in the
> TS text since it is not or not yet defined anywhere else, and
> maybe mention that it is expected that it will be removed later.
>
> In this way the feature is described and stable, and when
> as soon as part1 gets updated and the TS text gets moved from
> proposed to draft, one can remove it without having added
> or removed any functionality.
>
> > Michael,
> >
> > > Sounds like its time to get SIA back to TSS draft, Denis :)
> >
> > "son-of-RFC2459" has not yet passed WG last call, nor IESG
> last call.
> > Waiting for it would create a delay that could be estimated
> to be, at best,
> > about two months and thus would mean issuing the TSP RFC
> next year. :-(
> >
> > We now need this long-awaited RFC.
> >
> > Denis
> >
> > Note: I have just posted to the web editor an update
> (version 11) that
> > incorporates the changes that have been noticed (plus one,
> un-noticed in the
> > ASN1 module !)
>
----- End Included Message -----
Received: from edelweb.fr ([212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA21878 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 04:14:12 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA08538; Tue, 7 Nov 2000 13:20:57 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 7 Nov 2000 13:20:58 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA00961; Tue, 7 Nov 2000 13:20:57 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA04207; Tue, 7 Nov 2000 13:20:56 +0100 (MET)
Date: Tue, 7 Nov 2000 13:20:56 +0100 (MET)
Message-Id: <200011071220.NAA04207@emeriau.edelweb.fr>
To: Denis.Pinkas@bull.net, anders.rundgren@telia.com
Subject: Re: X509 ACs - Too late, too little
Cc: ietf-pkix@imc.org
>
> I.e. if you want to discuss XML-ACs you must do it somewhere else?
> Even if it addresses the very same applications and "market" as X509 ACs?
It might be interesting to see whether one could use an enhanced version of
XER in order to have a natual XML encoding of X.509 certs, i.e. being able
to have a pure XML encoding of an X.509 cert or other asn1 signed data with
a special xml signature canonicalisation that creates the DER encoding from
the XER encoding in order to verify the signature.
Would this be a work item for PKIX?
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA17881 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 03:21:59 -0800 (PST)
Received: from mega (t2o69p40.telia.com [62.20.144.160]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id MAA09382; Tue, 7 Nov 2000 12:28:47 +0100 (CET)
Message-ID: <008001c048ad$b4616e00$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Denis Pinkas" <Denis.Pinkas@bull.net>
Cc: "PKIX-List" <ietf-pkix@imc.org>
References: <006e01c048a7$5d3497c0$0201a8c0@vincent.se> <3A07E079.A472451@bull.net>
Subject: Re: X509 ACs - Too late, too little
Date: Tue, 7 Nov 2000 12:27:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA17887
Denis,
> This mailing list, called PKIX, means "PKI using X.509 certificates". This
> is what the "X" stands for.
XML-signatures use X509 certificates and PKI AFAIK.
> This mailing list does not deal with XML.
So PKIX cannot deal with any PKI-related structure if it is not already an ISO-std. and due to that
currently specified in ASN.1?
I.e. if you want to discuss XML-ACs you must do it somewhere else?
Even if it addresses the very same applications and "market" as X509 ACs?
Pardon me, did'nt know that.
/anders
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA13708 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 02:52:48 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA21100; Tue, 7 Nov 2000 12:05:22 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA25994; Tue, 7 Nov 2000 11:59:04 +0100
Message-ID: <3A07E079.A472451@bull.net>
Date: Tue, 07 Nov 2000 11:59:05 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: PKIX-List <ietf-pkix@imc.org>
Subject: Re: X509 ACs - Too late, too little
References: <006e01c048a7$5d3497c0$0201a8c0@vincent.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anders,
> XML-signatures are apparantly coming on strong.
> W3C now says the draft is in an advanced state.
>
> And IBM has kindly provided a reference implementation for public use at:
>
> http://www.alphaworks.ibm.com/tech/xmlsecuritysuite
>
> So why would anybody bother with ASN.1-based ACs?
>
> Neither ISO (particularly not ISO) nor the IETF can make ASN.1-based ACs
> an implementors choice if they do not quickly come up with something similar. And
> who would be interested in doing that? Sorry for being a PITA but I think
> that the AC-project should immediately be retargeted to use XML instead of becoming
> an RFC.
This mailing list, called PKIX, means "PKI using X.509 certificates". This
is what the "X" stands for. This mailing list does not deal with XML. ISO
has nearly completed the standard for ACs. In PKIX we define a profile for
this work. The market will decide to implement it or not.
If you are interested in XML and if you think it is appropriate, please
advocate XML ACs on the XML-DSIG mailing list <w3c-ietf-xmldsig@w3.org>
(i.e. not on the PKIX mailing list).
Denis
> Anders
Received: from d1o69.telia.com (root@d1o69.telia.com [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12657 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 02:36:36 -0800 (PST)
Received: from mega (t5o69p40.telia.com [213.64.110.40]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id LAA06675 for <ietf-pkix@imc.org>; Tue, 7 Nov 2000 11:43:23 +0100 (CET)
Message-ID: <006e01c048a7$5d3497c0$0201a8c0@vincent.se>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "PKIX-List" <ietf-pkix@imc.org>
Subject: X509 ACs - Too late, too little
Date: Tue, 7 Nov 2000 11:42:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA12660
XML-signatures are apparantly coming on strong.
W3C now says the draft is in an advanced state.
And IBM has kindly provided a reference implementation for public use at:
http://www.alphaworks.ibm.com/tech/xmlsecuritysuite
So why would anybody bother with ASN.1-based ACs?
Neither ISO (particularly not ISO) nor the IETF can make ASN.1-based ACs
an implementors choice if they do not quickly come up with something similar. And
who would be interested in doing that? Sorry for being a PITA but I think
that the AC-project should immediately be retargeted to use XML instead of becoming
an RFC.
Anders
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27718 for <ietf-pkix@imc.org>; Mon, 6 Nov 2000 11:34:52 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24044; Mon, 6 Nov 2000 11:41:33 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA06024; Mon, 6 Nov 2000 14:41:30 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA18132; Mon, 6 Nov 2000 14:41:29 -0500 (EST)
Message-ID: <3A0708ED.3B3EE241@sun.com>
Date: Mon, 06 Nov 2000 14:39:25 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
CC: ietf-pkix@imc.org
Subject: Re: Holder
References: <200011061513.KAA12206@roadblock.missi.ncsc.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"David P. Kemp" wrote:
> I don't support saying that AAs SHOULD use one of 4,8,1,3,5,7,9,11
> instead of 2. The profile should not say "*every* AA SHOULD avoid a
> useful option because *some* people trust 137 roots."
Yes. If you trust your PKI to securely map a name to a public key, then
it's perfectly appropriate to use format 2 in conjunction with a PKC. If
you don't trust your PKI, then you should probably use a format based on
the hash of the public key.
> > From: Steve Hanna <steve.hanna@sun.com>
> > So I suggest again that there's little reason to use formats 5, 7, and
> > 9. If the holder is a PKC, include all the available hints by using
> > format 11.
>
> BaseCertificateID (7 or 11) allows you to match without hashing
> every candidate, but that is a pretty minor benefit. Being able to
> search by issuer might be useful, although it doesn't seem to be widely
> supported now. The case against 11 (extra bulk in every AC) is pretty
> weak, but it might be important in low-bandwidth applications. The
> question boils down to "Do we know enough to recommend that every AC
> include information that is 'rarely' useful but could be 'slightly'
> harmful?"
>
> I don't have a dog in this race, so I don't have a strong preference
> for 9 only, 11 only, or all of 5,7,9,11. As long as the profile
> doesn't prohibit ACs using any of the 11 formats (by saying AAs MUST
> use some subset), I'm happy.
I also don't have a "dog in this race" (if by that you mean a product or
business that depends on the use of one of these formats). My main goal
is to increase interoperability. For this reason, I would like to see us
settle on a small number of formats that AC verifiers and issuers SHOULD
be able to verify and issue. Certainly, they MAY use any of the formats,
depending on their needs.
Are there low-bandwidth AC applications in the Internet domain? At
least, ones where 30 more bytes per AC would be likely to cause a
problem? If so, could someone provide an example?
-Steve
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10294 for <ietf-pkix@imc.org>; Mon, 6 Nov 2000 07:29:05 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id KAA12222 for <ietf-pkix@imc.org>; Mon, 6 Nov 2000 10:13:48 -0500 (EST)
Message-Id: <200011061513.KAA12206@roadblock.missi.ncsc.mil>
Date: Mon, 6 Nov 2000 10:28:24 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: kRnP+DqrFYcKz1XmxZUnUQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
> From: Polar Humenn <polar@adiron.com>
>
> Dave,
>
> I like your summary below and I agree with it.
>
> Question, would a suggestion adding that AA's SHOULD generate one of the
> 4,8,1,3,5,7,9,11 that they support instead of 2.
>
> Note that statement would only apply to where Public Key Certificates are
> the link to the holder.
>
> Cheers,
> -Polar
When PKCs are used, option 2 means that the holder is not a specific
PKC, it is any PKC used by the named entity. I believe that being able
to preserve attribute links when PKCs are rekeyed (or allowing a
subject to authenticate using his choice of PKCs) is a requirement, so
I don't support saying that AAs SHOULD use one of 4,8,1,3,5,7,9,11
instead of 2. The profile should not say "*every* AA SHOULD avoid a
useful option because *some* people trust 137 roots."
> From: Steve Hanna <steve.hanna@sun.com>
>
> So I suggest again that there's little reason to use formats 5, 7, and
> 9. If the holder is a PKC, include all the available hints by using
> format 11.
BaseCertificateID (7 or 11) allows you to match without hashing
every candidate, but that is a pretty minor benefit. Being able to
search by issuer might be useful, although it doesn't seem to be widely
supported now. The case against 11 (extra bulk in every AC) is pretty
weak, but it might be important in low-bandwidth applications. The
question boils down to "Do we know enough to recommend that every AC
include information that is 'rarely' useful but could be 'slightly'
harmful?"
I don't have a dog in this race, so I don't have a strong preference
for 9 only, 11 only, or all of 5,7,9,11. As long as the profile
doesn't prohibit ACs using any of the 11 formats (by saying AAs MUST
use some subset), I'm happy.
Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA00541 for <ietf-pkix@imc.org>; Mon, 6 Nov 2000 05:45:04 -0800 (PST)
Received: (qmail 15846 invoked from network); 6 Nov 2000 13:51:47 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 6 Nov 2000 13:51:47 -0000
Received: (qmail 14143 invoked from network); 6 Nov 2000 13:52:08 -0000
Received: from unknown (HELO mnystrom-lap.securitydynamics.com) (10.100.22.97) by spirit.dynas.se with SMTP; 6 Nov 2000 13:52:08 -0000
Date: Mon, 6 Nov 2000 08:51:51 -0500 (Eastern Standard Time)
From: Magnus Nystrom <magnus@rsasecurity.com>
To: wcwang@ms.chttl.com.tw
cc: ietf-pkix@imc.org
Subject: Re: WAP X.509 Certificate profile specification
In-Reply-To: <003901c04627$dab1ad00$c485900a@chttl.com.tw>
Message-ID: <Pine.WNT.4.10.10011060847020.-773557@mnystrom-lap.securitydynamics.com.>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Dear Wen Cheng,
Thanks for your comments.
On Sat, 4 Nov 2000, WCWANG wrote:
> Hi Magnus,
>
> I've downloaded the WAP X.509 certificate profile specification, and noticed
> that there is a recommendation on the length of Certificate Serial Number:
>
> 6.2.1 Certificate Serial Number
> CAs claiming conformance with this specification should avoid using
> serial numbers longer than 8 bytes (63 bits, topmost bit cannot be set to
> 1).
>
> I believe that the recommendation is due to the limit memory space and
> processing power of WAP device.
Yes, memory space and bandwidth savings...
> However, I suggest that the specification should extend the limitation
> on the length of certificate serial numbers from 8 bytes to at least
> 16 bytes, since there are many root CA's and intermediate
>
> CA's are currently usning 16-byte certificate serial numbers. By
> allowing merely more 8 bytes be used for certificate serial numbers,
> existing CA's may issue WAP-compliant certificates without changing
> their algorithms for generating certificate serial numbers.
Yes, but note that this is a recommendation (a "SHOULD") for CAs and not a
requirement.
Regards,
-- Magnus
> On Mon, 30 Oct 2000, Magnus Nystrom wrote:
>
> > Hi Tom,
> >
> > I would suggest that you send them directly to me, unless they are
> > pkix-related. I will make sure to forward them to WAP's security group
> > mailing list - and Cc: you.
> >
> > Thanks,
> > -- Magnus
> >
> > On Mon, 30 Oct 2000, Tom Arnold wrote:
> >
> > I've downloaded the document and am beginning to review it. My company is
> > not a member of the Wap Forum... As such, if I have comments, where
> should
> > I send them? I'm assuming the PKIX list is not the correct location...
> >
> > At 04:19 PM 10/26/2000 +0200, you wrote:
> > >Dear PKIX members,
> > >
> > >On behalf of WAP's security group WSG, I would like to inform you that
> > >a document named "WAPCert-20000309" can be found at
> > >
> > >http://www.wapforum.org/what/technical.htm.
> > >
> > >This document describes X.509 certificate profiles to be used for those
> > >cases when X.509-compliant certificates will be sent over-the-air in WAP
> > >protocols (or stored locally in WAP clients).
> > >
> > >An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> > >
> > >Comments and suggestions related to these documents are welcome and
> > >solicited.
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17657 for <ietf-pkix@imc.org>; Mon, 6 Nov 2000 02:43:30 -0800 (PST)
Received: from certplus.com ([192.168.212.171]) by certplus.com (8.8.7/8.8.7) with ESMTP id LAA14733 for <ietf-pkix@imc.org>; Mon, 6 Nov 2000 11:56:11 +0100
Message-ID: <3A068CCF.56574B9F@certplus.com>
Date: Mon, 06 Nov 2000 11:49:51 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Extended Key Usage and path validation
References: <613B3C619C9AD4118C4E00B0D03E7C3E136578@exchange.valicert.com> <v04220803b628fb6e83f8@[171.78.30.108]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Stephen Kent wrote:
> The Netscape discussion for this extension makes little or no sense
> to me, based on your description. As Frank notes, this is an
> extension one expects to see in an EE cert, vs. a CA cert, so one
> would not encounter multiple ones in validating a path. If I did use
> this extension in a CA cert, given the semantics, it might well
> conflict with an EE usage. Certainly the keyUasage bits for CA certs
> and EE certs are distinct, so why would one expect a relationship of
> the sort described for this extension.
Thank you Stephen for this clear comment.
I can now consider I have a definitive answer on that :-)
In fact, what Netscape describes is the behaviour of Microsoft products
today, not really it's own, as far as I understand.
Received: from firewall.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29540 for <ietf-pkix@imc.org>; Fri, 3 Nov 2000 22:17:07 -0800 (PST)
Received: from ms.chttl.com.tw (ms.tl.gov.tw. [10.144.2.104]) by firewall.chttl.com.tw (8.9.3/8.9.3) with ESMTP id OAA29847; Sat, 4 Nov 2000 14:23:08 +0800 (CST)
Received: from wcwangnt ([10.144.133.196]) by ms.chttl.com.tw (8.10.2/8.10.2) with SMTP id eA46RQj16764; Sat, 4 Nov 2000 14:27:26 +0800 (CST)
Message-ID: <003901c04627$dab1ad00$c485900a@chttl.com.tw>
From: =?big5?B?pP2k5aW/?= <wcwang@ms.chttl.com.tw>
To: <magnus@rsasecurity.com>
Cc: <ietf-pkix@imc.org>
Subject: Re: WAP X.509 Certificate profile specification
Date: Sat, 4 Nov 2000 14:24:15 +0800
Organization: =?big5?B?pKS12Llxq0is46hzqdI=?=
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Hi Magnus,
I've downloaded the WAP X.509 certificate profile specification, and noticed
that there is a recommendation on the length of Certificate Serial Number:
6.2.1 Certificate Serial Number
CAs claiming conformance with this specification should avoid using
serial numbers longer than 8 bytes (63 bits, topmost bit cannot be set to
1).
I believe that the recommendation is due to the limit memory space and
processing power of WAP device. However, I suggest that the specification
should extend the limitation on the length of certificate serial numbers
from
8 bytes to at least 16 bytes, since there are many root CA's and
intermediate
CA's are currently usning 16-byte certificate serial numbers. By allowing
merely more 8 bytes be used for certificate serial numbers, existing CA's
may issue WAP-compliant certificates without changing their algorithms for
generating certificate serial numbers.
--
Wen-Cheng Wang
Telecommunication Lab.
Chunghwa Telecom Co., Ltd.
On Mon, 30 Oct 2000, Magnus Nystrom wrote:
> Hi Tom,
>
> I would suggest that you send them directly to me, unless they are
> pkix-related. I will make sure to forward them to WAP's security group
> mailing list - and Cc: you.
>
> Thanks,
> -- Magnus
>
> On Mon, 30 Oct 2000, Tom Arnold wrote:
>
> I've downloaded the document and am beginning to review it. My company is
> not a member of the Wap Forum... As such, if I have comments, where
should
> I send them? I'm assuming the PKIX list is not the correct location...
>
> At 04:19 PM 10/26/2000 +0200, you wrote:
> >Dear PKIX members,
> >
> >On behalf of WAP's security group WSG, I would like to inform you that
> >a document named "WAPCert-20000309" can be found at
> >
> >http://www.wapforum.org/what/technical.htm.
> >
> >This document describes X.509 certificate profiles to be used for those
> >cases when X.509-compliant certificates will be sent over-the-air in WAP
> >protocols (or stored locally in WAP clients).
> >
> >An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> >
> >Comments and suggestions related to these documents are welcome and
> >solicited.
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21059 for <ietf-pkix@imc.org>; Fri, 3 Nov 2000 15:42:55 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA06010; Fri, 3 Nov 2000 18:49:15 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <v04220803b628fb6e83f8@[171.78.30.108]>
In-Reply-To: <613B3C619C9AD4118C4E00B0D03E7C3E136578@exchange.valicert.com>
References: <613B3C619C9AD4118C4E00B0D03E7C3E136578@exchange.valicert.com>
Date: Fri, 3 Nov 2000 18:35:15 -0500
To: Frank Balluffi <frankb@valicert.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Extended Key Usage and path validation
Cc: ietf-pkix <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Frank & Jean-marc,
The Netscape discussion for this extension makes little or no sense
to me, based on your description. As Frank notes, this is an
extension one expects to see in an EE cert, vs. a CA cert, so one
would not encounter multiple ones in validating a path. If I did use
this extension in a CA cert, given the semantics, it might well
conflict with an EE usage. Certainly the keyUasage bits for CA certs
and EE certs are distinct, so why would one expect a relationship of
the sort described for this extension.
Steve
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19865 for <ietf-pkix@imc.org>; Fri, 3 Nov 2000 14:39:06 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22232; Fri, 3 Nov 2000 14:45:36 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA25573; Fri, 3 Nov 2000 17:45:35 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id RAA13989; Fri, 3 Nov 2000 17:45:34 -0500 (EST)
Message-ID: <3A033F94.BEF8E980@sun.com>
Date: Fri, 03 Nov 2000 17:43:32 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
CC: ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
References: <200011022213.RAA25143@roadblock.missi.ncsc.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"David P. Kemp" wrote:
> I believe the profile should require support for at least one Holder
> option for each purpose.
Agreed. I think we have reached consensus on this.
> But I'm not sure that there is much
> simplification to be gained by not supporting certain combinations of
> search hints. In other words, if RPs are required to support 11,
> could they be made any simpler by not also supporting 5, 7, and 9?
Requiring support for more Holder formats will make the spec more
complex. This may or may not increase the amount of coding required. It
will certainly increase the effort required for product testing and
interoperability testing. It will also increase the complexity of the
spec. And it may increase the probability that implementations will
choose to not implement all required features in the spec, potentially
leading to incompatibilities (if I implement formats 5 and 7 and you
implement 9 and 11). Several recent IETF standards suffer from having
too many required options (or too few).
With respect to formats 5, 7, 9, and 11, the holder is a PKC. The AC
issuer has the PKC. Why not include all the hints available that might
help the AC verifier find the PKC? Someone asked why it might be useful
to include BCID. With BCID, the AC verifier can query its certificate
repository using the issuer name and serial number (and maybe the
subject name) and get a small number of certificates (probably one),
whose hash can then be compared against the PKC hash in the AC. With
only the entityName, the query to the certificate repository may return
many more certificates.
So I suggest again that there's little reason to use formats 5, 7, and
9. If the holder is a PKC, include all the available hints by using
format 11.
On the question of whether 4, 6, 8, or 10 is better, I want to consider
that over the weekend.
-Steve
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24708 for <ietf-pkix@imc.org>; Fri, 3 Nov 2000 06:03:44 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G3G00601COWAT@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 3 Nov 2000 06:10:08 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G3G005ENCOWTB@ext-mail.valicert.com>; Fri, 03 Nov 2000 06:10:08 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <V9V44STJ>; Fri, 03 Nov 2000 06:08:31 -0800
Content-return: allowed
Date: Fri, 03 Nov 2000 06:08:22 -0800
From: Frank Balluffi <frankb@valicert.com>
Subject: RE: Extended Key Usage and path validation
To: "'Jean-Marc Desperrier'" <jean-marc.desperrier@certplus.com>, ietf-pkix <ietf-pkix@imc.org>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E136578@exchange.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset="iso-8859-1"
Jean-Marc,
RFC 2459 doesn't say a whole lot about handling extended key usage
extensions. For example, section 6.1 of RFC 2459 contains one instance of
"usage":
"(m) If a key usage extension is marked critical, ensure the keyCertSign bit
is set."
which only makes sense for certificates 1 through n - 1. Note that section
6.1 does include:
"(h) Recognize and process any other critical extension present in the
certificate."
Extended key usage is commonly included in end-entity certificates to
authorize an end-entity to sign certain things. One example is signing OCSP
responses (see section 4.2.2.2 of RFC 2560).
So one way to look at this issue to:
- check key usage extensions as part of one's general-purpose path
validation
- check extended key usage as part of one's protocol-specific "signature
validation"
In this case, "signature validation" means verifying the signature plus
checking the signer's certificate.
I was unable to find any discussion about extended key usage in RFCs 2312
and 2632. So I am not sure what Netscape is saying about using extended key
usage in S/MIME. I wonder if Netscape's information is outdated.
Frank
> -----Original Message-----
> From: Jean-Marc Desperrier [mailto:jean-marc.desperrier@certplus.com]
> Sent: Thursday, November 02, 2000 2:24 PM
> To: ietf-pkix
> Subject: Extended Key Usage and path validation
>
>
> I've been trying recently to understand how path validation should be
> done for the usage of a key.
>
> Until now, the only document that I've found that's really explicit is
> the following from Netscape/iPlanet :
> http://docs.iplanet.com/docs/manuals/cms/41/dep_gide/ext.htm
>
> Netscape, in this document, says this about extended key usage in path
> validation.
>
> "A given certificate is valid only for the intersection of
> key usages of
> all the certificates in the chain to its root (as determined
> by both the
>
> Extended Key Usage extension for each certificate and the
> corresponding
> user settings). To be valid for a particular usage, the end-entity
> certificate and all certificates in the chain must all be
> valid for that
> usage"
>
> In fact, in the context it's not very clear whether this is what
> Netscape recommends or the current practice of Microsoft softwares.
>
> But their recommendation for certificat format in table B.1 of that
> document is perfectly coherent with that.
>
> This path validation does not apply to keyUsage.
> A CA with a keyUsage of keyCertSign, cRLSign, can perfectly
> emit a valid
> certificate with a keyUsage of digitalSignature.
>
> I've been reading through RFC2459, and I was not able able to find
> anything that really supports this behaviour.
>
> Is this actually the intended use of key usage and extended
> key usage ?
>
> For example Netscape recommends the following for a CA that
> signs S/MIME
> client certificate :
> extKeyUsage: Email
> keyUsage: keyCertSign, cRLSign
>
> But then extKeyUsage and keyUsage are not consistent each other.
> After RFC2459, "extKeyUsage: Email" is consistent with
> digitalSignature,
> but not with keyCertSign, cRLSign
>
> RFC2459 says the certificate MUST only be used for a purpose
> consistant
> with both fields and is invalid if none exist.
> This only applies when both are flagged critical, but if the correct
> setting of this values forbids you to set them critical, it
> sounds quite
> annoying.
> There should be an explicit table of what is compatible with what.
> I'm afraid not every implementer of RFC2459 will make the
> same decision
> of which values are compatible if trying to implement that with the
> current text in RFC2459.txt or draft-ietf-pkix-new-part1-02.txt.
>
> Now if extended key usage must not be used in path validation, then we
> loose the possibility to constraint the usage of a certificate in the
> CAs above it, except maybe through policy, but this is not
> something the
> software can interpret as easily as extended key usage.
>
> Should this way of using extKeyUsage be considered bad practice and
> avoided or not ?
>
> Isn't there the need for a PKIX document that would explicitely detail
> how a complex CA path should be set for various uses ? (if
> there is one
> that can effectively be used for that, I've missed it).
>
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14875 for <ietf-pkix@imc.org>; Fri, 3 Nov 2000 03:28:11 -0800 (PST)
Received: from certplus.com ([192.168.212.171]) by certplus.com (8.8.7/8.8.7) with ESMTP id MAA30663 for <ietf-pkix@imc.org>; Fri, 3 Nov 2000 12:40:11 +0100
Message-ID: <3A02A292.AEC84416@certplus.com>
Date: Fri, 03 Nov 2000 12:33:38 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Re: Extended Key Usage and path validation
References: <3A01BF34.B3723D9B@certplus.com> <005501c04575$f4154a20$666801c4@fcpl.co.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> ----- Original Message -----
> From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
> To: ietf-pkix <ietf-pkix@imc.org>
> Sent: Friday, November 03, 2000 12:53 AM
> Subject: Extended Key Usage and path validation
>
> > I've been trying recently to understand how path validation should be
> > done for the usage of a key.
> >
> > Until now, the only document that I've found that's really explicit is
> > the following from Netscape/iPlanet :
> > http://docs.iplanet.com/docs/manuals/cms/41/dep_gide/ext.htm
> >
> > Netscape, in this document, says this about extended key usage in path
> > validation.
> >
> > "A given certificate is valid only for the intersection of key usages of
> > all the certificates in the chain to its root (as determined by both the
> >
> > Extended Key Usage extension for each certificate and the corresponding
> > user settings). To be valid for a particular usage, the end-entity
> > certificate and all certificates in the chain must all be valid for that
> > usage"
Shantanu Bhattacharya wrote:
> In my view, the EKU should not be the intersection for the simple reason
> that one PKI vendor might decide his own EKU bit, but his CA's cert is not
> self signed and is issued by another PKI vendor who does support that EKU
> bit. This case can never be supported if the EKU is used as the intersection
> of all EKUs in the cert chain.
This is the purpose of this mecanism.
A signs the CA of B who decides to create certificate that uses a new EKU bit.
Either A has decided that he doesn't want to restrict B in any way.
He will not put any EKU in B's certificate, and B can use any EKU afterward.
Or A decides that he signs B, but only to emits S/MIME, or SSL certificates and
that he doesn't want B to use his endorsement of the B hierarchy to create
another kind of certificate.
He will put an EKU with S/MIME and SSL, and be sure that B will never be able to
use his certificate to sign anything else.
Now I believe this is not RFC2459 compliant, but it seems to be the behaviour of
some products, and a functionnality people wants (The netscape-cert-type
ssl/obj/emailCA bits had the same usage).
Received: from getafix.fcpl.co.in (getafix.fcpl.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA29070 for <ietf-pkix@imc.org>; Fri, 3 Nov 2000 00:53:34 -0800 (PST)
Received: from SHANTANU ([196.1.104.102]) by getafix.fcpl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WC0441QG; Fri, 3 Nov 2000 14:31:03 +0530
Message-ID: <005501c04575$f4154a20$666801c4@fcpl.co.in>
From: "Shantanu Bhattacharya" <shantanu@elock.co.in>
To: "Jean-Marc Desperrier" <jean-marc.desperrier@certplus.com>, "ietf-pkix" <ietf-pkix@imc.org>
References: <3A01BF34.B3723D9B@certplus.com>
Subject: Re: Extended Key Usage and path validation
Date: Fri, 3 Nov 2000 14:40:43 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In my view, the EKU should not be the intersection for the simple reason
that one PKI vendor might decide his own EKU bit, but his CA's cert is not
self signed and is issued by another PKI vendor who does support that EKU
bit. This case can never be supported if the EKU is used as the intersection
of all EKUs in the cert chain.
Regards
Shantanu Bhattacharya
Project Manager,
E-Lock Technologies Pvt. Ltd,
Opp Symphony Restaurant,
Pune, India.
----- Original Message -----
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
To: ietf-pkix <ietf-pkix@imc.org>
Sent: Friday, November 03, 2000 12:53 AM
Subject: Extended Key Usage and path validation
> I've been trying recently to understand how path validation should be
> done for the usage of a key.
>
> Until now, the only document that I've found that's really explicit is
> the following from Netscape/iPlanet :
> http://docs.iplanet.com/docs/manuals/cms/41/dep_gide/ext.htm
>
> Netscape, in this document, says this about extended key usage in path
> validation.
>
> "A given certificate is valid only for the intersection of key usages of
> all the certificates in the chain to its root (as determined by both the
>
> Extended Key Usage extension for each certificate and the corresponding
> user settings). To be valid for a particular usage, the end-entity
> certificate and all certificates in the chain must all be valid for that
> usage"
>
> In fact, in the context it's not very clear whether this is what
> Netscape recommends or the current practice of Microsoft softwares.
>
> But their recommendation for certificat format in table B.1 of that
> document is perfectly coherent with that.
>
> This path validation does not apply to keyUsage.
> A CA with a keyUsage of keyCertSign, cRLSign, can perfectly emit a valid
> certificate with a keyUsage of digitalSignature.
>
> I've been reading through RFC2459, and I was not able able to find
> anything that really supports this behaviour.
>
> Is this actually the intended use of key usage and extended key usage ?
>
> For example Netscape recommends the following for a CA that signs S/MIME
> client certificate :
> extKeyUsage: Email
> keyUsage: keyCertSign, cRLSign
>
> But then extKeyUsage and keyUsage are not consistent each other.
> After RFC2459, "extKeyUsage: Email" is consistent with digitalSignature,
> but not with keyCertSign, cRLSign
>
> RFC2459 says the certificate MUST only be used for a purpose consistant
> with both fields and is invalid if none exist.
> This only applies when both are flagged critical, but if the correct
> setting of this values forbids you to set them critical, it sounds quite
> annoying.
> There should be an explicit table of what is compatible with what.
> I'm afraid not every implementer of RFC2459 will make the same decision
> of which values are compatible if trying to implement that with the
> current text in RFC2459.txt or draft-ietf-pkix-new-part1-02.txt.
>
> Now if extended key usage must not be used in path validation, then we
> loose the possibility to constraint the usage of a certificate in the
> CAs above it, except maybe through policy, but this is not something the
> software can interpret as easily as extended key usage.
>
> Should this way of using extKeyUsage be considered bad practice and
> avoided or not ?
>
> Isn't there the need for a PKIX document that would explicitely detail
> how a complex CA path should be set for various uses ? (if there is one
> that can effectively be used for that, I've missed it).
Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA20737 for <ietf-pkix@imc.org>; Fri, 3 Nov 2000 00:02:24 -0800 (PST)
Received: (qmail 87667 invoked from network); 3 Nov 2000 08:08:45 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 3 Nov 2000 08:08:45 -0000
Received: (qmail 26153 invoked from network); 3 Nov 2000 08:09:06 -0000
Received: from mnystrom-lap.d.dynas.se (172.16.13.246) by spirit.dynas.se with SMTP; 3 Nov 2000 08:09:06 -0000
Date: Fri, 3 Nov 2000 09:07:06 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <magnus@rsasecurity.com>
To: Stefan Santesson <stefans@addtrust.com>
cc: "Jeffrey I. Schiller" <jis@mit.edu>, Stephen Kent <kent@bbn.com>, Tim Polk <wpolk@nist.gov>, Marcus Leech <mleech@nortelnetworks.com>, ietf-pkix@imc.org
Subject: Re: QC Document just passed the IESG
In-Reply-To: <5.0.0.25.2.20001103084617.03a1ec38@mail.addtrust.com>
Message-ID: <Pine.WNT.4.10.10011030903490.-832083@mnystrom-lap.d.dynas.se>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Stefan,
AFAIK, we can fix these during the "authors' 48 hours" (we'll receive an
email from rfc-ed when they are ready to publish and will then be given 48
hours to fix any minor editorial things, like spelling corrections).
If you want the RFC # in advance, you may want to check with
rfc-ed@isi.edu or Scott Bradner (sob@harvard.edu) directly.
-- Magnus
On Fri, 3 Nov 2000, Stefan Santesson wrote:
> Thank's Jeff - This is great news.
>
> Some minor questions:
> - How do we handle the small editorial updates (language corrections) that
> mentioned before (attached)
> - Is there any chance to get an RFC number before December 1st? (Needed for
> the EU standard).
> - Who should I discuss these matters with?
>
> /Stefan
>
> At 12:00 2000-11-02 -0500, Jeffrey I. Schiller wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >
> >The Qualified Certificates document <draft-ietf-pkix-qc-06.txt> just
> >passed during the IESG teleconference (within the last 5 minutes).
> >
> > -Jeff
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: PGP for Personal Privacy 5.0
> >Comment: Processed by Mailcrypt 3.5b6, an Emacs/PGP interface
> >Charset: noconv
> >
> >iQCVAwUBOgGdmcUtR20Nv5BtAQG+zQP/epO7LyN3RezUBhFK805+3Jnb/aQoXmHM
> >0rOHGz3TgUzbrcU5gRG1psA6vb0eZy6M/mbWY4jfWAtNk4850xFAZ9tDTsRYRmBD
> >PpMxDiOHfRqyiCdib802EmdUAtU8h8CLhOpbwDxCSA5FSrXs0DoBglj67f9B5+5q
> >QPD2Hhv11Hw=
> >=6y33
> >-----END PGP SIGNATURE-----
>
-- Magnus
Magnus Nystrom
RSA Security
Received: from mail.addtrust.com (IDENT:qmailr@[212.112.175.83]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA19217 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 23:48:31 -0800 (PST)
Received: (qmail 14225 invoked from network); 2 Nov 2000 14:50:15 -0000
Received: from unknown (HELO santesson.addtrust.com) (139.92.65.97) by 212.112.175.83 with SMTP; 2 Nov 2000 14:50:15 -0000
Message-Id: <5.0.0.25.2.20001103084617.03a1ec38@mail.addtrust.com>
X-Sender: sts@mail.addtrust.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 03 Nov 2000 08:54:43 +0100
To: "Jeffrey I. Schiller" <jis@mit.edu>
From: Stefan Santesson <stefans@addtrust.com>
Subject: Re: QC Document just passed the IESG
Cc: Stephen Kent <kent@bbn.com>, Tim Polk <wpolk@nist.gov>, Marcus Leech <mleech@nortelnetworks.com>, ietf-pkix@imc.org
In-Reply-To: <200011021700.MAA00577@localhost.localdomain>
References: <5.0.0.25.2.20001031092226.026a8bf0@mail.addtrust.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_1335950==_"
--=====================_1335950==_
Content-Type: text/plain; charset="us-ascii"; format=flowed
Thank's Jeff - This is great news.
Some minor questions:
- How do we handle the small editorial updates (language corrections) that
mentioned before (attached)
- Is there any chance to get an RFC number before December 1st? (Needed for
the EU standard).
- Who should I discuss these matters with?
/Stefan
At 12:00 2000-11-02 -0500, Jeffrey I. Schiller wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>The Qualified Certificates document <draft-ietf-pkix-qc-06.txt> just
>passed during the IESG teleconference (within the last 5 minutes).
>
> -Jeff
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP for Personal Privacy 5.0
>Comment: Processed by Mailcrypt 3.5b6, an Emacs/PGP interface
>Charset: noconv
>
>iQCVAwUBOgGdmcUtR20Nv5BtAQG+zQP/epO7LyN3RezUBhFK805+3Jnb/aQoXmHM
>0rOHGz3TgUzbrcU5gRG1psA6vb0eZy6M/mbWY4jfWAtNk4850xFAZ9tDTsRYRmBD
>PpMxDiOHfRqyiCdib802EmdUAtU8h8CLhOpbwDxCSA5FSrXs0DoBglj67f9B5+5q
>QPD2Hhv11Hw=
>=6y33
>-----END PGP SIGNATURE-----
--=====================_1335950==_
Content-Type: application/msword; name="Suggested editorial changes to draft06.doc";
x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Suggested editorial changes to draft06.doc"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALwAAAAAAAAAA
EAAAMQAAAAEAAAD+////AAAAAC4AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAOSAdBAAA8BK/AAAAAAAAEAAAAAAABAAASxcAAA4AYmpiav3P/c8AAAAAAAAAAAAAAAAAAAAA
AAAdBBYALiQAAJ+lAACfpQAASxMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAFABAAAAAAAAUAEAAFAB
AAAAAAAAUAEAAAAAAABQAQAAAAAAAFABAAAAAAAAUAEAABQAAAAAAAAAAAAAAGQBAAAAAAAAWAoA
AAAAAABYCgAAAAAAAFgKAAAAAAAAWAoAAAwAAABkCgAAJAAAAGQBAAAAAAAA0xEAAPYAAACUCgAA
AAAAAJQKAAAAAAAAlAoAAAAAAACUCgAAAAAAAJQKAAAAAAAAlAoAAAAAAACUCgAAAAAAAJQKAAAA
AAAAUhEAAAIAAABUEQAAAAAAAFQRAAAAAAAAVBEAAAAAAABUEQAAAAAAAFQRAAAAAAAAVBEAACQA
AADJEgAAIAIAAOkUAADSAAAAeBEAABUAAAAAAAAAAAAAAAAAAAAAAAAAUAEAAAAAAACUCgAAAAAA
AAAAAAAAAAAAAAAAAAAAAACUCgAAAAAAAJQKAAAAAAAAlAoAAAAAAACUCgAAAAAAAHgRAAAAAAAA
Zg4AAAAAAABQAQAAAAAAAFABAAAAAAAAlAoAAAAAAAAAAAAAAAAAAJQKAAAAAAAAjREAABYAAABm
DgAAAAAAAGYOAAAAAAAAZg4AAAAAAACUCgAAjgAAAFABAAAAAAAAlAoAAAAAAABQAQAAAAAAAJQK
AAAAAAAAUhEAAAAAAAAAAAAAAAAAAGYOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAlAoAAAAAAABSEQAAAAAAAGYOAADsAgAAZg4AAAAAAAAAAAAA
AAAAAFIRAAAAAAAAUAEAAAAAAABQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUhEAAAAAAACUCgAAAAAAAIgKAAAMAAAAwA27ZfUx
wAFkAQAA9AgAAFgKAAAAAAAAIgsAANoCAABSEQAAAAAAAAAAAAAAAAAAUhEAAAAAAACjEQAAMAAA
ANMRAAAAAAAAUhEAAAAAAAC7FQAAAAAAAPwNAABqAAAAuxUAAAAAAABSEQAAAAAAAGYOAAAAAAAA
ZAEAAAAAAABkAQAAAAAAAFABAAAAAAAAUAEAAAAAAABQAQAAAAAAAFABAAAAAAAAAgDZAAAAU3Vn
Z2VzdGVkIGVkaXRvcmlhbCBjaGFuZ2VzIHRvIGRyYWZ0LWlldGYtcGtpeC1xYy0wNi50eHQgc2lu
Y2UgSUVTRyBsYXN0IGNhbGwsIGVuZGVkIFNlcHRlbWJlciAyMg0NDUNoYW5nZSAxLCBzZWN0aW9u
IDMuMS4yDQ1DdXJyZW50IHdvcmRpbmc6DSAgIFRoZSBzdXJuYW1lIGFuZCBnaXZlbk5hbWUgYXR0
cmlidXRlIHR5cGVzIFNIQUxMLCBpZiBwcmVzZW50LCBjb250YWluDSAgIHRoZSByZWdpc3RlcmVk
IG5hbWUgb2YgdGhlIHN1YmplY3QsIGRlcGVuZGluZyBvbiB0aGUgbGF3cyB1bmRlciB3aGljaA0g
ICB0aGUgQ0EgcHJlcGFyZXMgdGhlIGNlcnRpZmljYXRlLiBUaGVzZSBhdHRyaWJ1dGVzIFNIQUxM
IGJlIHVzZWQgaW4NICAgdGhlIHN1YmplY3QgZmllbGQgaWYgdGhlIGNvbW1vbk5hbWUgYXR0cmli
dXRlIGlzIG5vdCBwcmVzZW50LiBJbg0gICBjYXNlcyB3aGVyZSB0aGUgc3ViamVjdCBvbmx5IGhh
cyBhIHNpbmdsZSBuYW1lIHJlZ2lzdGVyZWQsIHRoZQ0gICBnaXZlbk5hbWUgYXR0cmlidXRlIFNI
QUxMIGJlIHVzZWQgYW5kIHRoZSBzdXJuYW1lIGF0dHJpYnV0ZSBTSEFMTCBiZQ0gICBvbWl0dGVk
Lg0gDVN1Z2dlc3RlZCBuZXcgd29yZGluZzoNICAgVGhlIHN1cm5hbWUgYW5kIGdpdmVuTmFtZSBh
dHRyaWJ1dGUgdHlwZXMgU0hBTEwsIGlmIHByZXNlbnQsIGNvbnRhaW4NICAgdGhlIHJlZ2lzdGVy
ZWQgbmFtZSBvZiB0aGUgc3ViamVjdCwgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBsYXdzIHVuZGVy
DSAgIHdoaWNoIHRoZSBDQSBwcmVwYXJlcyB0aGUgY2VydGlmaWNhdGUuIFRoZXNlIGF0dHJpYnV0
ZXMgU0hBTEwgYmUgdXNlZA0gICBpbiB0aGUgc3ViamVjdCBmaWVsZCBpZiB0aGUgY29tbW9uTmFt
ZSBhdHRyaWJ1dGUgaXMgbm90IHByZXNlbnQuIEluDSAgIGNhc2VzIHdoZXJlIHRoZSBzdWJqZWN0
IG9ubHkgaGFzIGEgc2luZ2xlIG5hbWUgcmVnaXN0ZXJlZCwgdGhlDSAgIGdpdmVuTmFtZSBhdHRy
aWJ1dGUgU0hBTEwgYmUgdXNlZCBhbmQgdGhlIHN1cm5hbWUgYXR0cmlidXRlIFNIQUxMIGJlDSAg
IG9taXR0ZWQuDSANQ2hhbmdlIDIsIHNlY3Rpb24gMy4yLjENDUN1cnJlbnQgd29yZGluZzoNICAg
VGhlIGNvdW50cnlPZkNpdGl6ZW5zaGlwIGF0dHJpYnV0ZSBTSEFMTCwgd2hlbiBwcmVzZW50LCBj
b250YWluIHRoZQ0gICBpZGVudGlmaWVyIG9mIGF0IGxlYXN0IG9uZSBvZiB0aGUgc3ViamVjdCdz
IGNsYWltZWQgY291bnRyeSBvZg0gICBjaXRpemVuc2hpcCBhdCB0aGUgdGltZSB0aGF0IHRoZSBj
ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkLiBJZiB0aGUNICAgc3ViamVjdCBpcyBhIGNpdGl6ZW4gb2Yg
bW9yZSB0aGFuIG9uZSBjb3VudHJ5LCBtb3JlIHRoYW4gb25lIGNvdW50cnkNICAgTUFZIGJlIHBy
ZXNlbnQuIERldGVybWluYXRpb24gb2YgY2l0aXplbnNoaXAgaXMgYSBtYXR0ZXIgb2YgbGF3IGFu
ZA0gICBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0gDVN1Z2dlc3RlZCBu
ZXcgd29yZGluZzoNICAgVGhlIGNvdW50cnlPZkNpdGl6ZW5zaGlwIGF0dHJpYnV0ZSBTSEFMTCwg
d2hlbiBwcmVzZW50LCBjb250YWluIHRoZQ0gICBpZGVudGlmaWVyIG9mIGF0IGxlYXN0IG9uZSBv
ZiB0aGUgc3ViamVjdCdzIGNsYWltZWQgY291bnRyaWVzIG9mDSAgIGNpdGl6ZW5zaGlwIGF0IHRo
ZSB0aW1lIHRoYXQgdGhlIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQuIElmIHRoZQ0gICBzdWJqZWN0
IGlzIGEgY2l0aXplbiBvZiBtb3JlIHRoYW4gb25lIGNvdW50cnksIG1vcmUgdGhhbiBvbmUgY291
bnRyeQ0gICBNQVkgYmUgcHJlc2VudC4gRGV0ZXJtaW5hdGlvbiBvZiBjaXRpemVuc2hpcCBpcyBh
IG1hdHRlciBvZiBsYXcgYW5kDSAgIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1l
bnQuDSANQ2hhbmdlIDMsIHNlY3Rpb24gMy4yLjQNDUN1cnJlbnQgd29yZGluZzoNICAgSXQgaXMg
UkVDT01NRU5ERUQgdGhhdCBiaW9tZXRyaWMgaW5mb3JtYXRpb24gaW4gdGhpcyBleHRlbnNpb24g
YXJlDSAgIGxpbWl0ZWQgdG8gaW5mb3JtYXRpb24gdHlwZXMgc3VpdGFibGUgZm9yIGh1bWFuIHZl
cmlmaWNhdGlvbiwgaS5lLiwNICAgd2hlcmUgdGhlIGRlY2lzaW9uIG9mIHdoZXRoZXIgdGhlIGlu
Zm9ybWF0aW9uIGlzIGFuIGFjY3VyYXRlDSAgIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBzdWJqZWN0
IGlzIG5hdHVyYWxseSBwZXJmb3JtZWQgYnkgYSBwZXJzb24uDSAgIFRoaXMgaW1wbGllcyBhIHVz
YWdlIHdoZXJlIHRoZSBiaW9tZXRyaWMgaW5mb3JtYXRpb24gaXMgcmVwcmVzZW50ZWQNICAgYnks
IGZvciBleGFtcGxlLCBhIGdyYXBoaWNhbCBpbWFnZSBkaXNwbGF5ZWQgdG8gdGhlIHJlbHlpbmcg
cGFydHksDSAgIHdoaWNoIE1BWSBiZSB1c2VkIGJ5IHRoZSByZWx5aW5nIHBhcnR5IHRvIGVuaGFu
Y2UgaWRlbnRpZmljYXRpb24gb2YNICAgdGhlIHN1YmplY3QuDSANU3VnZ2VzdGVkIG5ldyB3b3Jk
aW5nOg0gICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGJpb21ldHJpYyBpbmZvcm1hdGlvbiBpbiB0
aGlzIGV4dGVuc2lvbiBpcw0gICBsaW1pdGVkIHRvIGluZm9ybWF0aW9uIHR5cGVzIHN1aXRhYmxl
IGZvciBodW1hbiB2ZXJpZmljYXRpb24sIGkuZS4sDSAgIHdoZXJlIHRoZSBkZWNpc2lvbiBvZiB3
aGV0aGVyIHRoZSBpbmZvcm1hdGlvbiBpcyBhbiBhY2N1cmF0ZQ0gICByZXByZXNlbnRhdGlvbiBv
ZiB0aGUgc3ViamVjdCBpcyBuYXR1cmFsbHkgcGVyZm9ybWVkIGJ5IGEgcGVyc29uLg0gICBUaGlz
IGltcGxpZXMgYSB1c2FnZSB3aGVyZSB0aGUgYmlvbWV0cmljIGluZm9ybWF0aW9uIGlzIHJlcHJl
c2VudGVkDSAgIGJ5LCBmb3IgZXhhbXBsZSwgYSBncmFwaGljYWwgaW1hZ2UgZGlzcGxheWVkIHRv
IHRoZSByZWx5aW5nIHBhcnR5LA0gICB3aGljaCBNQVkgYmUgdXNlZCBieSB0aGUgcmVseWluZyBw
YXJ0eSB0byBlbmhhbmNlIGlkZW50aWZpY2F0aW9uIG9mDSAgIHRoZSBzdWJqZWN0LiANDUNoYW5n
ZSA0LCBzZWN0aW9uIDQNDUN1cnJlbnQgd29yZGluZzoNICAgU2luY2UgdGhlIHB1YmxpYyBrZXlz
IGFyZSBmb3IgcHVibGljIHVzZSB3aXRoIGxlZ2FsIGltcGxpY2F0aW9ucyBmb3INICAgaW52b2x2
ZWQgcGFydGllcywgY2VydGFpbiBjb25kaXRpb25zIHNob3VsZCBleGlzdCBiZWZvcmUgQ0FzIGlz
c3Vlcw0gICBjZXJ0aWZpY2F0ZXMgYXMgUXVhbGlmaWVkIENlcnRpZmljYXRlcy4gVGhlIGFzc29j
aWF0ZWQgcHJpdmF0ZSBrZXlzDSAgIG11c3QgYmUgdW5pcXVlIGZvciB0aGUgc3ViamVjdCwgYW5k
IG11c3QgYmUgbWFpbnRhaW5lZCB1bmRlciB0aGUNICAgc3ViamVjdCdzIHNvbGUgY29udHJvbC4g
IFRoYXQgaXMsIGEgQ0Egc2hvdWxkIG5vdCBpc3N1ZSBhIHF1YWxpZmllZA0gICBjZXJ0aWZpY2F0
ZSBpZiB0aGUgbWVhbnMgdG8gdXNlIHRoZSBwcml2YXRlIGtleSBpcyBub3QgcHJvdGVjdGVkDSAg
IGFnYWluc3QgdW5pbnRlbmRlZCB1c2FnZS4gIFRoaXMgaW1wbGllcyB0aGF0IHRoZSBDQSBoYXZl
IHNvbWUNICAga25vd2xlZGdlIGFib3V0IHRoZSBzdWJqZWN0J3MgY3J5cHRvZ3JhcGhpYyBtb2R1
bGUuDSANU3VnZ2VzdGVkIG5ldyB3b3JkaW5nOg0gICBTaW5jZSB0aGUgcHVibGljIGtleXMgYXJl
IGZvciBwdWJsaWMgdXNlIHdpdGggbGVnYWwgaW1wbGljYXRpb25zIGZvcg0gICBpbnZvbHZlZCBw
YXJ0aWVzLCBjZXJ0YWluIGNvbmRpdGlvbnMgc2hvdWxkIGV4aXN0IGJlZm9yZSBDQXMgaXNzdWUN
ICAgY2VydGlmaWNhdGVzIGFzIFF1YWxpZmllZCBDZXJ0aWZpY2F0ZXMuIFRoZSBhc3NvY2lhdGVk
IHByaXZhdGUga2V5cw0gICBtdXN0IGJlIHVuaXF1ZSBmb3IgdGhlIHN1YmplY3QsIGFuZCBtdXN0
IGJlIG1haW50YWluZWQgdW5kZXIgdGhlDSAgIHN1YmplY3QncyBzb2xlIGNvbnRyb2wuICBUaGF0
IGlzLCBhIENBIHNob3VsZCBub3QgaXNzdWUgYSBxdWFsaWZpZWQNICAgY2VydGlmaWNhdGUgaWYg
dGhlIG1lYW5zIHRvIHVzZSB0aGUgcHJpdmF0ZSBrZXkgaXMgbm90IHByb3RlY3RlZA0gICBhZ2Fp
bnN0IHVuaW50ZW5kZWQgdXNhZ2UuICBUaGlzIGltcGxpZXMgdGhhdCB0aGUgQ0EgaGF2ZSBzb21l
DSAgIGtub3dsZWRnZSBhYm91dCB0aGUgc3ViamVjdCdzIGNyeXB0b2dyYXBoaWMgbW9kdWxlLg0g
DUNoYW5nZSA1LCBzZWN0aW9uIDQNDUN1cnJlbnQgd29yZGluZzoNICAgVGhlIGFiaWxpdHkgdG8g
Y29tcGFyZSB0d28gcXVhbGlmaWVkIGNlcnRpZmljYXRlcyB0byBkZXRlcm1pbmUgaWYNICAgdGhl
eSByZXByZXNlbnQgdGhlIHNhbWUgcGh5c2ljYWwgZW50aXR5IGlzIGRlcGVuZGVudCBvbiB0aGUg
c2VtYW50aWNzDSAgIG9mIHRoZSBzdWJqZWN0cyBuYW1lcy4gVGhlIHNlbWFudGljcyBvZiBhIHBh
cnRpY3VsYXIgYXR0cmlidXRlIG1heSBiZQ0gICBkaWZmZXJlbnQgZm9yIGRpZmZlcmVudCBpc3N1
ZXJzLiBDb21wYXJpbmcgbmFtZXMgd2l0aG91dCBrbm93bGVkZ2Ugb2YNICAgdGhlIHNlbWFudGlj
cyBvZiBuYW1lcyBpbiB0aGVzZSBwYXJ0aWN1bGFyIGNlcnRpZmljYXRlcyBtYXkgcHJvdmlkZQ0g
ICBtaXNsZWFkaW5nIHJlc3VsdHMuDSANU3VnZ2VzdGVkIG5ldyB3b3JkaW5nOg0gICBUaGUgYWJp
bGl0eSB0byBjb21wYXJlIHR3byBxdWFsaWZpZWQgY2VydGlmaWNhdGVzIHRvIGRldGVybWluZSBp
Zg0gICB0aGV5IHJlcHJlc2VudCB0aGUgc2FtZSBwaHlzaWNhbCBlbnRpdHkgaXMgZGVwZW5kZW50
IG9uIHRoZSBzZW1hbnRpY3MNICAgb2YgdGhlIHN1YmplY3RzkiBuYW1lcy4gVGhlIHNlbWFudGlj
cyBvZiBhIHBhcnRpY3VsYXIgYXR0cmlidXRlIG1heSBiZQ0gICBkaWZmZXJlbnQgZm9yIGRpZmZl
cmVudCBpc3N1ZXJzLiBDb21wYXJpbmcgbmFtZXMgd2l0aG91dCBrbm93bGVkZ2Ugb2YNICAgdGhl
IHNlbWFudGljcyBvZiBuYW1lcyBpbiB0aGVzZSBwYXJ0aWN1bGFyIGNlcnRpZmljYXRlcyBtYXkg
cHJvdmlkZQ0gICBtaXNsZWFkaW5nIHJlc3VsdHMuDSANDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAjgQAAD8GAABY
BgAAxwYAANkGAAAPCAAAOwgAAMAJAADZCQAAVwoAAGAKAABgCwAAjAsAAIINAACbDQAA3Q0AAN8N
AACPDwAAuA8AANURAADuEQAAdhIAAHsSAAAKFAAAMhQAALAVAADJFQAAYRYAAGoWAABIFwAASxcA
APvu++7b7vvu++7b7vvu++7b7vvu++7b7vvu++7b7vsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkPioBQioGQ0oUAE9KAwBRSgMAXkoDAG1ICQhwaP8A
AABzSAkIABhDShQAT0oDAFFKAwBeSgMAbUgJCHNICQgACG1ICQhzSAkIHwAEAABiBAAAYwQAAGQE
AAB8BAAAfQQAAI4EAADWBAAAHwUAAGUFAACpBQAA6wUAADMGAAA/BgAAQQYAAFgGAACgBgAA6QYA
ADIHAAB5BwAAuwcAAAMIAAAPCAAAEQgAACkIAAAqCAAAOwgAAIIIAADECAAABwkAAP0AAAAAAAAA
AAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA+QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
APsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAAAAABAgAAAQAAAAEBAAAdAAQAAEsXAAD9AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQEHCQAATwkAAJYJAADACQAA
wgkAANkJAAAgCgAAZAoAAKcKAADvCgAANgsAAGALAABiCwAAegsAAHsLAACMCwAA0gsAABkMAABZ
DAAAngwAAOUMAAArDQAAcg0AAIINAACEDQAAmw0AAOANAAAnDgAAZw4AAKwOAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAECAAABAAAAHawOAADzDgAAOQ8AAIAPAACR
DwAAkg8AAKYPAACnDwAAuA8AAAAQAABHEAAAjhAAANIQAAAZEQAAXREAAJ4RAADVEQAA1xEAAO4R
AAA2EgAAfBIAAMMSAAAHEwAAThMAAJITAADTEwAAChQAAAwUAAAgFAAAIRQAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAQIAAAEAAAAdIRQAADIUAAB3FAAAwBQAAAkV
AABSFQAAmRUAALAVAACyFQAAyRUAAA4WAABXFgAAoRYAAOoWAAAxFwAASBcAAEoXAABLFwAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAABEsADGQaAEfsIIuILDGQSGwiQUi
sIkFI5CJBSSQiQUlsAAAF7DEAhiwxAIMkMQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQADwAKAAEAaQAPAAMAAAAAAAAA
AAA4AABA8f8CADgADAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgdBHNIHQR0
SB0EUAABQAEAAgBQAAwACABSAHUAYgByAGkAawAgADEAAAAQAAEABiQBE6TwABSkPABAJgAeADUI
gUNKIABLSCAAT0oCAFFKAgBcCIFeSgIAYUogAFIAAkABAAIAUgAMAAgAUgB1AGIAcgBpAGsAIAAy
AAAAEAACAAYkAROk8AAUpDwAQCYBIAA1CIE2CIFDShwAT0oCAFFKAgBcCIFdCIFeSgIAYUocAAAA
AAAAAAAAAAAAAAAAQgBBQPL/oQBCAAwAGQBTAHQAYQBuAGQAYQByAGQAcwB0AHkAYwBrAGUAdABl
AGMAawBlAG4AcwBuAGkAdAB0AAAAAAAAAAAAAAAAAAAAAABLEwAABAAAJAAABgD/////AAAAAGIA
AABjAAAAZAAAAHwAAAB9AAAAjgAAANYAAAAfAQAAZQEAAKkBAADrAQAAMwIAAD8CAABBAgAAWAIA
AKACAADpAgAAMgMAAHkDAAC7AwAAAwQAAA8EAAARBAAAKQQAACoEAAA7BAAAggQAAMQEAAAHBQAA
TwUAAJYFAADABQAAwgUAANkFAAAgBgAAZAYAAKcGAADvBgAANgcAAGAHAABiBwAAegcAAHsHAACM
BwAA0gcAABkIAABZCAAAnggAAOUIAAArCQAAcgkAAIIJAACECQAAmwkAAOAJAAAnCgAAZwoAAKwK
AADzCgAAOQsAAIALAACRCwAAkgsAAKYLAACnCwAAuAsAAAAMAABHDAAAjgwAANIMAAAZDQAAXQ0A
AJ4NAADVDQAA1w0AAO4NAAA2DgAAfA4AAMMOAAAHDwAATg8AAJIPAADTDwAAChAAAAwQAAAgEAAA
IRAAADIQAAB3EAAAwBAAAAkRAABSEQAAmREAALARAACyEQAAyREAAA4SAABXEgAAoRIAAOoSAAAx
EwAASBMAAEoTAABNEwAAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw
AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA
AAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA
AIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA
AACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACA
mEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA
AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw
AAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA
AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA
AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA
AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA
mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAA
AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAw
AAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA
AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA
AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA
AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA
mEAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA
AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw
AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAA
AAAAAIAAAACAGAAAAAIwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAA
AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA
AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA
mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA
AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw
AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA
AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA
AIAAAACAGAAAAAIwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAA
AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA
mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA
AAAwAAAAAAAAAIAAAACAmEAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw
AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA
AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA
AIAAAACAAAQAAEsXAAAMAAAAAAQAAAcJAACsDgAAIRQAAEsXAAANAAAADwAAABAAAAARAAAAAAQA
AEsXAAAOAAAAAAAAAD8AAABDAAAAoQAAAKoAAACBAQAAiwEAAO4BAAD3AQAAawIAAHQCAABRAwAA
WwMAAL4DAADHAwAAQgQAAFYEAADgBQAA9AUAADwMAAA/DAAAcg4AAHUOAABNEwAABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAADZAAAA3AAAACIBAAAlAQAA
aAEAAGsBAACsAQAAsQEAAO4BAAD3AQAANgIAAD0CAACjAgAApgIAAOwCAADxAgAANQMAADcDAAB8
AwAAgQMAAL4DAADHAwAABgQAAA0EAACFBAAAjwQAAMcEAADSBAAACgUAABEFAACZBQAAmwUAACMG
AAAtBgAAZwYAAHIGAACqBgAAsQYAADkHAAA7BwAAzgcAANEHAADVBwAA3AcAABwIAAAhCAAAXAgA
AGoIAADoCAAA6ggAAC4JAAAzCQAAdQkAAHgJAADdCQAA3wkAAOMJAADqCQAAKgoAAC8KAABqCgAA
eAoAAPYKAAD4CgAAPAsAAEELAACDCwAAhgsAAAMMAAALDAAASgwAAFYMAACRDAAAlQwAANUMAADe
DAAAHA0AACcNAABgDQAAZw0AAJQNAACYDQAAoQ0AAKoNAAA5DgAAQQ4AAH8OAACLDgAAxg4AAMoO
AAAKDwAAEw8AAFEPAABcDwAAlQ8AAJwPAADJDwAAzQ8AANYPAADfDwAAehAAAH4QAADDEAAAxRAA
AAwRAAAVEQAAVREAAFgRAACcEQAAphEAABESAAAVEgAAWhIAAFwSAACkEgAArRIAAO0SAADwEgAA
NBMAAD4TAABNEwAABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAAAAAAZAAAAH0AAAARBAAAKgQAAGIHAAB7BwAAdQkA
AIEJAACCCQAAhAkAAJILAACnCwAADBAAACEQAACcEQAAshEAAE0TAAAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFAAcA//8GAAAAEABTAHQAZQBmAGEAbgAgAFMAYQBuAHQAZQBzAHMAbwBu
AGsAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAHMA
dABzAC4AUwBBAE4AVABFAFMAUwBPAE4AXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABh
AFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAxQB0AGUAcgBzAGsAYQBwAG4AaQBuAGcA
cwBpAG4AZgBvACAAZgD2AHIAIABEAG8AawB1AG0AZQBuAHQAMQAuAGEAcwBkABAAUwB0AGUAZgBh
AG4AIABTAGEAbgB0AGUAcwBzAG8AbgBpAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQA
IABTAGUAdAB0AGkAbgBnAHMAXABzAHQAcwAuAFMAQQBOAFQARQBTAFMATwBOAFwATQBpAG4AYQAg
AGQAbwBrAHUAbQBlAG4AdABcAF4AUABLAEkAWAAtAFEAQwBcAFMAdQBnAGcAZQBzAHQAZQBkACAA
ZQBkAGkAdABvAHIAaQBhAGwAIABjAGgAYQBuAGcAZQBzACAAdABvACAAZAByAGEAZgB0ADAANgAu
AGQAbwBjABAAUwB0AGUAZgBhAG4AIABTAGEAbgB0AGUAcwBzAG8AbgBpAEMAOgBcAEQAbwBjAHUA
bQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABzAHQAcwAuAFMAQQBOAFQARQBT
AFMATwBOAFwATQBpAG4AYQAgAGQAbwBrAHUAbQBlAG4AdABcAF4AUABLAEkAWAAtAFEAQwBcAFMA
dQBnAGcAZQBzAHQAZQBkACAAZQBkAGkAdABvAHIAaQBhAGwAIABjAGgAYQBuAGcAZQBzACAAdABv
ACAAZAByAGEAZgB0ADAANgAuAGQAbwBjAP9AA4ABAEoTAABKEwAAHJl4AAEAAQBKEwAAAAAAAEoT
AAAAAAAAAhAAAAAAAAAASxMAAEAAAAgAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAA
AAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAQAAABHFpABAAACAgYDBQQF
AgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A
AAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAz
JpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAA
AgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAA
ACIABABxCIgYAPAYBQAAqQEAAAAAxktKJuBLSiYAAAAAAgAaAAAAygIAAOgPAAABAAgAAAAEAAMQ
IQAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAACBIwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AACJBYkFtAC0AIGBMjAAAAAAAAAAAAAAAAAAAIgTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAEygxEA8BAA
CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAANABTAHUAZwBnAGUAcwB0
AGUAZAAgAGUAZABpAHQAbwByAGkAYQBsACAAYwBoAGEAbgBnAGUAcwAgAHQAbwAgAGQAcgBhAGYA
dAAtAGkAZQB0AGYALQBwAGsAaQB4AC0AcQBjAC0AMAA2AAAAAAAAABAAUwB0AGUAZgBhAG4AIABT
AGEAbgB0AGUAcwBzAG8AbgAQAFMAdABlAGYAYQBuACAAUwBhAG4AdABlAHMAcwBvAG4AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf
8vlPaBCrkQgAKyez2TAAAACwAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAA2AAAAAQAAADkAAAA
BQAAAAABAAAGAAAADAEAAAcAAAAYAQAACAAAACgBAAAJAAAARAEAABIAAABQAQAACgAAAGwBAAAM
AAAAeAEAAA0AAACEAQAADgAAAJABAAAPAAAAmAEAABAAAACgAQAAEwAAAKgBAAACAAAA5AQAAB4A
AAA1AAAAU3VnZ2VzdGVkIGVkaXRvcmlhbCBjaGFuZ2VzIHRvIGRyYWZ0LWlldGYtcGtpeC1xYy0w
NgAAZAAeAAAAAQAAAAB1Z2ceAAAAEQAAAFN0ZWZhbiBTYW50ZXNzb24AYWwgHgAAAAEAAAAAdGVm
HgAAAAEAAAAAdGVmHgAAAAcAAABOb3JtYWwAUx4AAAARAAAAU3RlZmFuIFNhbnRlc3NvbgBhbCAe
AAAAAgAAADIAZWYeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDkuMAAgQAAAAAAc1aEDAAAAQAAAAACs
d6vxMcABQAAAAADITE31McABAwAAAAEAAAADAAAAygIAAAMAAADoDwAAAwAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cI
ACss+a4wAAAAJAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIQAAAAGAAAAjAAAABEAAACUAAAA
FwAAAJwAAAALAAAApAAAABAAAACsAAAAEwAAALQAAAAWAAAAvAAAAA0AAADEAAAADAAAAAUBAAAC
AAAA5AQAAB4AAAAMAAAAQWRkVHJ1c3QgQUIAAwAAACEAAAADAAAACAAAAAMAAACIEwAAAwAAAPwK
CQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAANQAAAFN1Z2dlc3RlZCBl
ZGl0b3JpYWwgY2hhbmdlcyB0byBkcmFmdC1pZXRmLXBraXgtcWMtMDYADBAAAAIAAAAeAAAABgAA
AFRpdGVsAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAA
AA0AAAAOAAAADwAAABAAAAARAAAAEgAAAP7///8UAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAA
GwAAABwAAAAdAAAA/v///x8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAD+////JwAAACgAAAAp
AAAAKgAAACsAAAAsAAAALQAAAP7////9////MAAAAP7////+/////v//////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAA
AAAAwHfTZfUxwAEyAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAP///////////////wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMAAAC7FQAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUA
bgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBQAAAP//////
////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4kAAAAAAAABQBTAHUA
bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAA
ABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABp
AG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAACYAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAATwBiAGoAZQBjAHQAUABvAG8AbAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQD/////////////
//8AAAAAAAAAAAAAAAAAAAAAAAAAAMB302X1McABwHfTZfUxwAEAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAEAAAD+////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARg4AAABXb3JkLWRva3VtZW50AAoAAABN
U1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA=
--=====================_1335950==_--
Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA04807 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 22:19:26 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.11) id JAA03883; Fri, 3 Nov 2000 09:26:12 +0300 (MSK)
Message-Id: <200011030626.JAA03883@relay1.trustworks.com>
Received: from svan-pc(212.114.5.100) by zuka via smap (V2.0) id xma003854; Fri, 3 Nov 00 09:25:23 +0300
From: "Valery Smyslov" <svan@trustworks.com>
Organization: TWS
To: Polar Humenn <polar@adiron.com>, Steve Hanna <steve.hanna@sun.com>
Date: Fri, 3 Nov 2000 09:24:57 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
CC: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Priority: normal
In-reply-to: <3A01D6C3.D77D7A0@sun.com>
X-mailer: Pegasus Mail for Win32 (v3.12b)
On 2 Nov 00, at 16:04, Steve Hanna wrote:
> Polar Humenn wrote:
> > On Thu, 2 Nov 2000, Steve Hanna wrote:
> > > Polar Humenn wrote:
> > > > On Thu, 2 Nov 2000, Steve Hanna wrote:
> > > > > The goal of the ac509prof draft is to define a profile of X.509
> > > > > attribute certificates for use with Internet protocols.
> > > >
> > > > Below you asked me for specific examples. So, can you please give me an a
> > > > definite list of which Internet protocols are supposed to support this
> > > > attribute certificate?
> > >
> > > ac509prof says "The profile places emphasis on attribute certificate
> > > support for Internet electronic mail, IPsec, and WWW security
> > > applications." So I expect that S/MIME, IPsec, and TLS would be the most
> > > important protocols for this profile.
> >
> > Do any of these protocols have facility for AC's?
>
> I'm certainly not an expert with all of these protocols. S/MIME does
> include attribute certificate support. IPsec and TLS seem to need more
> work.
IPsec (IKE) has build-in facility to transport AC certificates.
Regards,
Valery.
Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17201 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 15:40:41 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id SAA05374; Thu, 2 Nov 2000 18:42:42 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 2 Nov 2000 18:42:42 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: Ron Monzillo <Ronald.Monzillo@east.sun.com>
cc: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
In-Reply-To: <3A01F3D1.996E79F@east.sun.com>
Message-ID: <Pine.LNX.4.10.10011021811040.143-100000@marcy.adiron.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 2 Nov 2000, Ron Monzillo wrote:
>
>
> "David P. Kemp" wrote:
> >
> <snip>
>
> > I'd recommend that AAs SHOULD generate 8 instead of 4, and SHOULD
> > generate 9 instead of 1, 3, 5, 7, or 11. In the case of 9 vs. 11, its
> > not a case where "more is better" applies. BaseCertificateID doesn't
> > help with searching or with security, it just takes up space in the
> > AC.
>
> I agree with the rest, but doesn't the relative value of
> 11(BCId+EN+ODCERT) vs 9(EN+ODCERT) depend on whether you look up your
> PKC's by issuer or by by subject. It would seem that both options are
> possible with 11, but not with 9.
Can you give me an example of when you look up certificates by issuer
instead of subject?
I don't disagree with using 11, because the subject may have many
certificates stored under its DN, and the IssuerSerial is probably a
plausible way to different it that (with of course, ODCert). But it is
redundant with the ODcert, because you can just go down your list of certs
under the entityName, hash and compare. Okay, it's not that fast, but it's
doable. Time/space trade off. However, in things like SSL and S/MIME you
are going to be handed the certificates, and although not required, you'll
probably use them, so you are looking for verification of the link, not
looking for the certificate itself.
On the public key hash issue, I still think using 8 over 4 is problematic.
I think that if only a public key is relied upon, there shouldn't be a DN
associated with it. The DN is certificate specific and really has no
relation to a public key without a certificate. So hash the certificate
tying the DN to the public key, option 9 or 11, if the DN is needed at
all.
I really don't understand how you try to find a public key with a DN, i.e.
without regard to a certificate. Second of all, if you're doing any kind
of verification at the RP, you've probably already FOUND the public key
before you started working with the AC.
If you have a public key and your looking for the the matching AC out of
list of ACs you have, then just match on the hash. The EN becomes extra
space.
Also, if the entity name in the AC is different than the one the client
may have gave you, it could cause confusion. Same public key, different
CAs.
I would still go for generating 4 instead of 8 for simplicity and less
confusion. If there is a need to include the DN of the Holder, the
certificate hash should be there, which is one of 5,7,9,11. Preference of
which I don't really care. I think 1 and 3 should be avoided due to the DN
naming conflict issue. Option 2 should only be supported when PKCs are not
involved.
Cheers,
-Polar
> I think we should focus on 2,8, and 11
>
> Ron
>
> <snip>
>
-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:polar@adiron.com 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16006 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 15:05:33 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA115384; Thu, 2 Nov 2000 18:11:28 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id SAA91470; Thu, 2 Nov 2000 18:11:06 -0500
Importance: Normal
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Cc: ietf-pkix@imc.org
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFF5884629.B4CD18BF-ON8525698B.007E9D40@somers.hqregion.ibm.com>
From: "Tom Gindin/Watson/IBM" <tgindin@us.ibm.com>
Date: Thu, 2 Nov 2000 18:11:50 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.5 |September 22, 2000) at 11/02/2000 06:12:00 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
I won't argue with a preference for case 9 over case 11 - entityName
and baseCertificateID are indeed redundant with each other when
objectDigestInfo is present, and entityName is usually better for
searching. I do think we should align the RP MUST's with the AA SHOULD's.
Thus, an RP MUST support cases 2, 8 (assuming that that's more popular than
4) and 9. For backward compatibility, should we say that an RP MUST
support case 1 as well, or can we just skip it?
An RP which only supported 2, 8, and 9 would have relatively simple
code to locate the PKC - find by entityName.
Tom Gindin
"David P. Kemp" <dpkemp@missi.ncsc.mil> on 11/02/2000 05:27:25 PM
Please respond to "David P. Kemp" <dpkemp@missi.ncsc.mil>
To: ietf-pkix@imc.org
cc:
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
> From: Steve Hanna <steve.hanna@sun.com>
>
> As described above, I don't agree that option 11 is necessarily superior
> to option 10. However, I do agree that option 11 is superior to option
> 3.
Here is a regrouping of the options by purpose, with the search hints
appearing after the "+":
AC attached to Holder
-------------- -----------------------
Name 2) entityName
Public Key 4) Digest(publicKey)
8) Digest(publicKey) + entityName
6) Digest(publicKey) + baseCertificateID
10) Digest(publicKey) + baseCertificateID, entityName
PK Certificate 1) baseCertificateID
3) baseCertificateID + entityName
5) Digest(Cert)
9) Digest(Cert) + entityName
7) Digest(Cert) + baseCertificateID
11) Digest(Cert) + baseCertificateID, entityName
Bob and Sharon have pointed out that baseCertificateID is not very
useful as a search hint; it is only useful to identify one specific
PKC. If you are looking for certificates that contain a particular
public key, baseCertificateID is not likely to help you find one. For
that reason, I agree with Tom that 6) and 10) do not serve any purpose
and should not be used. Including baseCertificateID with a hash of a
public key is more confusing than helpful.
I believe the profile should require support for at least one Holder
option for each purpose. But I'm not sure that there is much
simplification
to be gained by not supporting certain combinations of search
hints. In other words, if RPs are required to support 11, could they be
made any simpler by not also supporting 5, 7, and 9?
> Tom Gindin:
>
> So I would recommend that RP's MUST support cases 2 and 11, SHOULD
> support cases 7 and 9, and I'd poll the group on whether 4 is better than
8
> or not.
I'd recommend that AAs:
MUST support 2,
MUST support at least one of {4, 8}, and
MUST support at least one of {1, 3, 5, 7, 9, 11}.
I'd recommend that AAs SHOULD NOT generate ACs using 6 or 10.
I'd recommend that AAs SHOULD generate 8 instead of 4, and SHOULD
generate 9 instead of 1, 3, 5, 7, or 11. In the case of 9 vs. 11, its
not a case where "more is better" applies. BaseCertificateID doesn't
help with searching or with security, it just takes up space in the
AC.
I don't have a preference concerning RPs. As above, if the profile
were to say RPs MUST support 10 and 11, then an RP developer would only
be hurting interoperability without simplifying code by choosing not to
support the other combinations. If the profile were to say RPs MUST
support 1, 2, and 3, and SHOULD support the others, the minimum
interoperable RP is simpler, and the recommended RP is more complex but
more robust in unmanaged PMI environments.
Dave
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15675 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 15:01:43 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02917; Thu, 2 Nov 2000 16:08:08 -0700 (MST)
Received: from suneast.East.Sun.COM (suneast.East.Sun.COM [129.148.9.3]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA23757; Thu, 2 Nov 2000 18:08:07 -0500 (EST)
Received: from jse.East.Sun.COM (jse [129.148.70.27]) by suneast.East.Sun.COM (8.9.3+Sun/8.8.8) with ESMTP id SAA13496; Thu, 2 Nov 2000 18:08:07 -0500 (EST)
Received: from east.sun.com (dhcp-71-230 [129.148.71.230]) by jse.East.Sun.COM (8.9.3+Sun/8.9.0) with ESMTP id SAA27638; Thu, 2 Nov 2000 18:08:07 -0500 (EST)
Message-ID: <3A01F3D1.996E79F@east.sun.com>
Date: Thu, 02 Nov 2000 18:08:01 -0500
From: Ron Monzillo <Ronald.Monzillo@east.sun.com>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
CC: ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
References: <200011022213.RAA25143@roadblock.missi.ncsc.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"David P. Kemp" wrote:
>
<snip>
> I'd recommend that AAs SHOULD generate 8 instead of 4, and SHOULD
> generate 9 instead of 1, 3, 5, 7, or 11. In the case of 9 vs. 11, its
> not a case where "more is better" applies. BaseCertificateID doesn't
> help with searching or with security, it just takes up space in the
> AC.
I agree with the rest, but doesn't the relative value of
11(BCId+EN+ODCERT)
vs 9(EN+ODCERT) depend on whether you look up your PKC's by issuer or by
by subject. It would seem that both options are possible with 11,
but not with 9.
I think we should focus on 2,8, and 11
Ron
<snip>
Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15107 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 14:44:40 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id RAA05295; Thu, 2 Nov 2000 17:46:43 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 2 Nov 2000 17:46:42 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
cc: ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
In-Reply-To: <200011022213.RAA25143@roadblock.missi.ncsc.mil>
Message-ID: <Pine.LNX.4.10.10011021740190.143-100000@marcy.adiron.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Dave,
I like your summary below and I agree with it.
Question, would a suggestion adding that AA's SHOULD generate one of the
4,8,1,3,5,7,9,11 that they support instead of 2.
Note that statement would only apply to where Public Key Certificates are
the link to the holder.
Cheers,
-Polar
On Thu, 2 Nov 2000, David P. Kemp wrote:
>
> > From: Steve Hanna <steve.hanna@sun.com>
> >
> > As described above, I don't agree that option 11 is necessarily superior
> > to option 10. However, I do agree that option 11 is superior to option
> > 3.
>
>
> Here is a regrouping of the options by purpose, with the search hints
> appearing after the "+":
>
> AC attached to Holder
> -------------- -----------------------
> Name 2) entityName
>
> Public Key 4) Digest(publicKey)
> 8) Digest(publicKey) + entityName
> 6) Digest(publicKey) + baseCertificateID
> 10) Digest(publicKey) + baseCertificateID, entityName
>
> PK Certificate 1) baseCertificateID
> 3) baseCertificateID + entityName
> 5) Digest(Cert)
> 9) Digest(Cert) + entityName
> 7) Digest(Cert) + baseCertificateID
> 11) Digest(Cert) + baseCertificateID, entityName
>
>
> Bob and Sharon have pointed out that baseCertificateID is not very
> useful as a search hint; it is only useful to identify one specific
> PKC. If you are looking for certificates that contain a particular
> public key, baseCertificateID is not likely to help you find one. For
> that reason, I agree with Tom that 6) and 10) do not serve any purpose
> and should not be used. Including baseCertificateID with a hash of a
> public key is more confusing than helpful.
>
> I believe the profile should require support for at least one Holder
> option for each purpose. But I'm not sure that there is much simplification
> to be gained by not supporting certain combinations of search
> hints. In other words, if RPs are required to support 11, could they be
> made any simpler by not also supporting 5, 7, and 9?
>
>
>
> > Tom Gindin:
> >
> > So I would recommend that RP's MUST support cases 2 and 11, SHOULD
> > support cases 7 and 9, and I'd poll the group on whether 4 is better than 8
> > or not.
>
> I'd recommend that AAs:
> MUST support 2,
> MUST support at least one of {4, 8}, and
> MUST support at least one of {1, 3, 5, 7, 9, 11}.
>
> I'd recommend that AAs SHOULD NOT generate ACs using 6 or 10.
>
> I'd recommend that AAs SHOULD generate 8 instead of 4, and SHOULD
> generate 9 instead of 1, 3, 5, 7, or 11. In the case of 9 vs. 11, its
> not a case where "more is better" applies. BaseCertificateID doesn't
> help with searching or with security, it just takes up space in the
> AC.
>
> I don't have a preference concerning RPs. As above, if the profile
> were to say RPs MUST support 10 and 11, then an RP developer would only
> be hurting interoperability without simplifying code by choosing not to
> support the other combinations. If the profile were to say RPs MUST
> support 1, 2, and 3, and SHOULD support the others, the minimum
> interoperable RP is simpler, and the recommended RP is more complex but
> more robust in unmanaged PMI environments.
>
> Dave
>
-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:polar@adiron.com 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14365 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 14:28:16 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id RAA25147 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 17:13:07 -0500 (EST)
Message-Id: <200011022213.RAA25143@roadblock.missi.ncsc.mil>
Date: Thu, 2 Nov 2000 17:27:25 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 6va8upVsBxmLZKoNzJLL7Q==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
> From: Steve Hanna <steve.hanna@sun.com>
>
> As described above, I don't agree that option 11 is necessarily superior
> to option 10. However, I do agree that option 11 is superior to option
> 3.
Here is a regrouping of the options by purpose, with the search hints
appearing after the "+":
AC attached to Holder
-------------- -----------------------
Name 2) entityName
Public Key 4) Digest(publicKey)
8) Digest(publicKey) + entityName
6) Digest(publicKey) + baseCertificateID
10) Digest(publicKey) + baseCertificateID, entityName
PK Certificate 1) baseCertificateID
3) baseCertificateID + entityName
5) Digest(Cert)
9) Digest(Cert) + entityName
7) Digest(Cert) + baseCertificateID
11) Digest(Cert) + baseCertificateID, entityName
Bob and Sharon have pointed out that baseCertificateID is not very
useful as a search hint; it is only useful to identify one specific
PKC. If you are looking for certificates that contain a particular
public key, baseCertificateID is not likely to help you find one. For
that reason, I agree with Tom that 6) and 10) do not serve any purpose
and should not be used. Including baseCertificateID with a hash of a
public key is more confusing than helpful.
I believe the profile should require support for at least one Holder
option for each purpose. But I'm not sure that there is much simplification
to be gained by not supporting certain combinations of search
hints. In other words, if RPs are required to support 11, could they be
made any simpler by not also supporting 5, 7, and 9?
> Tom Gindin:
>
> So I would recommend that RP's MUST support cases 2 and 11, SHOULD
> support cases 7 and 9, and I'd poll the group on whether 4 is better than 8
> or not.
I'd recommend that AAs:
MUST support 2,
MUST support at least one of {4, 8}, and
MUST support at least one of {1, 3, 5, 7, 9, 11}.
I'd recommend that AAs SHOULD NOT generate ACs using 6 or 10.
I'd recommend that AAs SHOULD generate 8 instead of 4, and SHOULD
generate 9 instead of 1, 3, 5, 7, or 11. In the case of 9 vs. 11, its
not a case where "more is better" applies. BaseCertificateID doesn't
help with searching or with security, it just takes up space in the
AC.
I don't have a preference concerning RPs. As above, if the profile
were to say RPs MUST support 10 and 11, then an RP developer would only
be hurting interoperability without simplifying code by choosing not to
support the other combinations. If the profile were to say RPs MUST
support 1, 2, and 3, and SHOULD support the others, the minimum
interoperable RP is simpler, and the recommended RP is more complex but
more robust in unmanaged PMI environments.
Dave
Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13490 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 14:02:32 -0800 (PST)
Received: from speedy.rtfm.com ([198.144.203.243]) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id OAA19025; Thu, 2 Nov 2000 14:08:57 -0800 (PST)
Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by speedy.rtfm.com (8.9.1/8.6.4) with ESMTP id MAA12295; Thu, 2 Nov 2000 12:15:10 -0800 (PST)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id OAA24370; Thu, 2 Nov 2000 14:12:39 -0800 (PST)
Sender: ekr@rtfm.com
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Cc: ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
References: <200011022139.QAA22239@roadblock.missi.ncsc.mil>
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <ekr@rtfm.com>
Date: 02 Nov 2000 14:12:39 -0800
In-Reply-To: "David P. Kemp"'s message of "Thu, 2 Nov 2000 16:53:40 -0500 (EST)"
Message-ID: <kj4s1qkoq0.fsf@romeo.rtfm.com>
Lines: 17
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
"David P. Kemp" <dpkemp@missi.ncsc.mil> writes:
> > From: Eric Rescorla <ekr@rtfm.com>
> >
> > > ac509prof says "The profile places emphasis on attribute certificate
> > > support for Internet electronic mail, IPsec, and WWW security
> > > applications." So I expect that S/MIME, IPsec, and TLS would be the most
> > > important protocols for this profile.
> >
> > TLS, at least, would need to be modified to use ACs. The issue is that
> > RFC 2246 explicitly specifies the order in which certificates must
> > appear:
>
> No, TLS would need to be modified to *carry* ACs.
Quite so. Thanks for the clarification.
-Ekr
Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13112 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 13:54:32 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id QAA22243 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 16:39:23 -0500 (EST)
Message-Id: <200011022139.QAA22239@roadblock.missi.ncsc.mil>
Date: Thu, 2 Nov 2000 16:53:40 -0500 (EST)
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Reply-To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
To: ietf-pkix@imc.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: EteDyr2sB9fVd94jzvpCjg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
> From: Eric Rescorla <ekr@rtfm.com>
>
> > ac509prof says "The profile places emphasis on attribute certificate
> > support for Internet electronic mail, IPsec, and WWW security
> > applications." So I expect that S/MIME, IPsec, and TLS would be the most
> > important protocols for this profile.
>
> TLS, at least, would need to be modified to use ACs. The issue is that
> RFC 2246 explicitly specifies the order in which certificates must
> appear:
No, TLS would need to be modified to *carry* ACs. The server could
easily query a directory or database to fetch ACs once the client has
authenticated. Since this wouldn't require client mods, and servers are
controlled by the information owners, TLS is likely to be one of the
first places where ACs are used.
Dave
Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12294 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 13:26:03 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id QAA05126; Thu, 2 Nov 2000 16:28:03 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 2 Nov 2000 16:28:02 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: Steve Hanna <steve.hanna@sun.com>
cc: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
In-Reply-To: <3A01D6C3.D77D7A0@sun.com>
Message-ID: <Pine.LNX.4.10.10011021606030.143-100000@marcy.adiron.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 2 Nov 2000, Steve Hanna wrote:
<snip>
> > PKCs delivered via TLS, RP pulls the AC from somewhere and wants to make
> > sure the correct PKC is used. Make sure the "context" in which he is
> > operating is defined by the correct certificate, because the certificate
> > contains "certified" information, such as the key is used to sign
> > transactions over $1,000,000,000 Turkish Lire. (or should I add a couple
> > more zeros?) :)
>
> If the RP has a PKC that he trusts which says that the user's key is
> trusted for billion lire operations, what difference does it make
> whether it's the same PKC that the AC issuer had in mind? The RP trusts
> the PKC because the PKI says it's trustworthy.
I guess what I meant was that, at least in protocols where the PKC is
delivered by the client, it places a context on the signatures done by its
public key. The AC is stating that attributes only apply to that context.
The PKC can have other pertinent information in it, such as a bank account
number, an audit identity, all that kind of stuff you didn't want to copy
into an AC (otherwise, we'd just include the entire PKC!).
> Or are you saying that the RP should trust the PKC because its hash is
> in the AC. In that case, why all the indirection? If you don't trust
> the PKI to get you a valid PKC, don't use the PKI.
No, what I am saying is that the RP shouldn't trust the AC if the hash
doesn't match the PKC.
> And put any security-sensitive information (like the billion lire
> signing authority) in the AC. Just use ACs with a PK ODI.
If that was the case, why wouldn't we just use to Bob Jeunman's suggestion
of just including all the Attribute information in a different PKC with
the users private key, certifying the signature, identity constraints,
attributes, etc, etc. which contains all the information in a delegated
sense. We'd be down to one certificate chain verification instead of two,
and some correlation work. The need for the AC goes away, S/MIME, IPsec,
TLS does not need to be reworked.
Unfortunately, this approach is not desirable,and also issuing attributes
to alternate naming schemes, such as Kerberos or RFC822, or Roles names
would be problematic.
> > > > Option 11 is definitely preferable where PKCs are used. Options 7 and 9
> > > > are desirable from a stand point of verifying the certificate being
> > > > pointed to, i.e. in those Internet protocols where the RP must look up
> > > > certificates.
> > >
> > > Why would 7 (BCID & PKC ODI) or 9 (EN & PKC ODI) be preferable to 11
> > > (BCID, EN, & PKC ODI) when the RP must look up certificates? I would
> > > expect that 11 would indisputably be the best in this circumstance,
> > > since it provides more hints to the RP.
> >
> > Okay, I'll agree. If that is your point, then 7 and 9 should be excluded
> > in favor of always using 11. So, that means any inconsitency in the EN and
> > the BCID should be ignored as long as the hash checks out. Just as long as
> > that is explicitly said.
> >
> > So anyway, whats the harm in supporting 7 and 9 then? Would you say that
> > if an RP is presented with 7 and 9 you should always reject it,
> > regardless?
> >
> > I think there has to be a dual notion of "support" here, one for issuers
> > and one for "verifiers", in sort of along the lines of "be conservative in
> > what you send and generous in what you receive". Perhaps, verifiers should
> > support 7,9,and 11, but issuers SHOULD only issue 11 in the cases where
> > ACs are tied to PKCs.
>
> If we see no reason to use formats 7 and 9, we shouldn't tell verifiers
> that they SHOULD implement them. Certainly, they MAY implement them. But
> there's no reason for them to waste the time, money, and code space on
> doing so.
I don't get it. Are you saying that they have to spend the time money and
code space to look for 7 and 9 and REJECT the AC? Or should it just core
dump? :)
> > > > And as for 4 and 8, I would say 4 is preferable to 8, because, 8 can lead
> > > > to inconsistencies. Where only the public key matters (i.e. the holder of
> > > > the matching private key) it shouldn't matter what DN it has. If it does
> > > > matter, then it should hash the certificate that ties the DN to the key.
> > > > In SSL, if the AC is only concerned with the public key, then the DN may
> > > > yield an inconsistency. The user may have delivered PKC with his public key
> > > > but a different DN.
> > >
> > > I don't see how including hints that might help the RP find certs would
> > > hurt anything. If the user has presented a PKC whose subject name does
> > > not match the entityName but the public key matches the PK ODI, then
> > > there's no problem. The entityName is just a hint.
> >
> > As long as that is explicitly stated in the document. So, in TLS if I am
> > delivered a PK certificate, I can ignore the EN and BCID from the AC
> > altoghether and just go for the PKC hash. However, I think there is
> > something in profile that states that the Entity Name MUST match the PK
> > certificate's subject DN.
>
> That note predates this discussion. Clearly the Holder and ODI sections
> need to be rewritten.
Agreed.
Cheers,
-Polar
> -Steve
>
-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:polar@adiron.com 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11527 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 12:59:44 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02415; Thu, 2 Nov 2000 13:06:07 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA03347; Thu, 2 Nov 2000 16:06:05 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id QAA24149; Thu, 2 Nov 2000 16:06:04 -0500 (EST)
Message-ID: <3A01D6C3.D77D7A0@sun.com>
Date: Thu, 02 Nov 2000 16:04:03 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <polar@adiron.com>
CC: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
References: <Pine.LNX.4.10.10011021450260.143-100000@marcy.adiron.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Polar Humenn wrote:
> On Thu, 2 Nov 2000, Steve Hanna wrote:
> > Polar Humenn wrote:
> > > On Thu, 2 Nov 2000, Steve Hanna wrote:
> > > > The goal of the ac509prof draft is to define a profile of X.509
> > > > attribute certificates for use with Internet protocols.
> > >
> > > Below you asked me for specific examples. So, can you please give me an a
> > > definite list of which Internet protocols are supposed to support this
> > > attribute certificate?
> >
> > ac509prof says "The profile places emphasis on attribute certificate
> > support for Internet electronic mail, IPsec, and WWW security
> > applications." So I expect that S/MIME, IPsec, and TLS would be the most
> > important protocols for this profile.
>
> Do any of these protocols have facility for AC's?
I'm certainly not an expert with all of these protocols. S/MIME does
include attribute certificate support. IPsec and TLS seem to need more
work.
> > Sure. If you can identify an important reason why one of these formats
> > is needed for the protocols of concern to us, then we should keep it.
> > Otherwise, we should not.
>
> Well, I think I did identify that you at least need a tie to the public
> key.
Yes, thank you for pointing that out.
> > > > If it is crucial that a particular AC be used only in combination with a
> > > > particular PKC, then I have no objection to allowing format 11. However,
> > > > I would be more convinced if you had a specific example.
> > >
> > > I thought I just did.
> >
> > Could you be more specific?
>
> PKCs delivered via TLS, RP pulls the AC from somewhere and wants to make
> sure the correct PKC is used. Make sure the "context" in which he is
> operating is defined by the correct certificate, because the certificate
> contains "certified" information, such as the key is used to sign
> transactions over $1,000,000,000 Turkish Lire. (or should I add a couple
> more zeros?) :)
If the RP has a PKC that he trusts which says that the user's key is
trusted for billion lire operations, what difference does it make
whether it's the same PKC that the AC issuer had in mind? The RP trusts
the PKC because the PKI says it's trustworthy. Or are you saying that
the RP should trust the PKC because its hash is in the AC. In that case,
why all the indirection? If you don't trust the PKI to get you a valid
PKC, don't use the PKI. Just use ACs with a PK ODI. And put any
security-sensitive information (like the billion lire signing authority)
in the AC.
> > > Option 11 is definitely preferable where PKCs are used. Options 7 and 9
> > > are desirable from a stand point of verifying the certificate being
> > > pointed to, i.e. in those Internet protocols where the RP must look up
> > > certificates.
> >
> > Why would 7 (BCID & PKC ODI) or 9 (EN & PKC ODI) be preferable to 11
> > (BCID, EN, & PKC ODI) when the RP must look up certificates? I would
> > expect that 11 would indisputably be the best in this circumstance,
> > since it provides more hints to the RP.
>
> Okay, I'll agree. If that is your point, then 7 and 9 should be excluded
> in favor of always using 11. So, that means any inconsitency in the EN and
> the BCID should be ignored as long as the hash checks out. Just as long as
> that is explicitly said.
>
> So anyway, whats the harm in supporting 7 and 9 then? Would you say that
> if an RP is presented with 7 and 9 you should always reject it,
> regardless?
>
> I think there has to be a dual notion of "support" here, one for issuers
> and one for "verifiers", in sort of along the lines of "be conservative in
> what you send and generous in what you receive". Perhaps, verifiers should
> support 7,9,and 11, but issuers SHOULD only issue 11 in the cases where
> ACs are tied to PKCs.
If we see no reason to use formats 7 and 9, we shouldn't tell verifiers
that they SHOULD implement them. Certainly, they MAY implement them. But
there's no reason for them to waste the time, money, and code space on
doing so.
> > > And as for 4 and 8, I would say 4 is preferable to 8, because, 8 can lead
> > > to inconsistencies. Where only the public key matters (i.e. the holder of
> > > the matching private key) it shouldn't matter what DN it has. If it does
> > > matter, then it should hash the certificate that ties the DN to the key.
> > > In SSL, if the AC is only concerned with the public key, then the DN may
> > > yield an inconsistency. The user may have delivered PKC with his public key
> > > but a different DN.
> >
> > I don't see how including hints that might help the RP find certs would
> > hurt anything. If the user has presented a PKC whose subject name does
> > not match the entityName but the public key matches the PK ODI, then
> > there's no problem. The entityName is just a hint.
>
> As long as that is explicitly stated in the document. So, in TLS if I am
> delivered a PK certificate, I can ignore the EN and BCID from the AC
> altoghether and just go for the PKC hash. However, I think there is
> something in profile that states that the Entity Name MUST match the PK
> certificate's subject DN.
That note predates this discussion. Clearly the Holder and ODI sections
need to be rewritten.
-Steve
Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08705 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 12:03:42 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id PAA05007; Thu, 2 Nov 2000 15:05:38 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 2 Nov 2000 15:05:37 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: Steve Hanna <steve.hanna@sun.com>
cc: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
In-Reply-To: <3A01C58C.A8CD8CB8@sun.com>
Message-ID: <Pine.LNX.4.10.10011021450260.143-100000@marcy.adiron.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 2 Nov 2000, Steve Hanna wrote:
> Polar Humenn wrote:
> > On Thu, 2 Nov 2000, Steve Hanna wrote:
> > > The goal of the ac509prof draft is to define a profile of X.509
> > > attribute certificates for use with Internet protocols.
> >
> > Below you asked me for specific examples. So, can you please give me an a
> > definite list of which Internet protocols are supposed to support this
> > attribute certificate?
>
> ac509prof says "The profile places emphasis on attribute certificate
> support for Internet electronic mail, IPsec, and WWW security
> applications." So I expect that S/MIME, IPsec, and TLS would be the most
> important protocols for this profile.
Do any of these protocols have facility for AC's?
> > > As such, it is to be expected that we will make recommendations about
> > > which features SHOULD or MUST be supported.
> > >
> > > It's unlikely that most implementors will want to support all 11 formats
> > > listed above. If we can identify one or two formats that are sufficient
> > > for use with Internet protocols and recommend that those formats be
> > > supported, then we can increase the chances of successful
> > > interoperation. If we make no such recommendations, it's unlikely that
> > > we can achieve this.
> >
> > I understand that. But different applications and different protocols need
> > different things.
>
> Sure. If you can identify an important reason why one of these formats
> is needed for the protocols of concern to us, then we should keep it.
> Otherwise, we should not.
Well, I think I did identify that you at least need a tie to the public
key.
> > > If it is crucial that a particular AC be used only in combination with a
> > > particular PKC, then I have no objection to allowing format 11. However,
> > > I would be more convinced if you had a specific example.
> >
> > I thought I just did.
>
> Could you be more specific?
PKCs delivered via TLS, RP pulls the AC from somewhere and wants to make
sure the correct PKC is used. Make sure the "context" in which he is
operating is defined by the correct certificate, because the certificate
contains "certified" information, such as the key is used to sign
transactions over $1,000,000,000 Turkish Lire. (or should I add a couple
more zeros?) :)
> > > This would also allow us to support role specification certificates
> > > (which assign privileges or attributes to a role). I realized after
> > > sending my email that we cannot support them with formats 4-11, because
> > > a role does not have a public key. And I suppose that we do want to
> > > support them, since we discuss them in section 4.4.5.
> >
> > Well, that's problematic on how you define the role. A role also needs
> > scoping information, like "who's role". Is a role defined by a DN?
>
> The roleAuthority field defines the scope for a role.
>
> > Option 11 is definitely preferable where PKCs are used. Options 7 and 9
> > are desirable from a stand point of verifying the certificate being
> > pointed to, i.e. in those Internet protocols where the RP must look up
> > certificates.
>
> Why would 7 (BCID & PKC ODI) or 9 (EN & PKC ODI) be preferable to 11
> (BCID, EN, & PKC ODI) when the RP must look up certificates? I would
> expect that 11 would indisputably be the best in this circumstance,
> since it provides more hints to the RP.
Okay, I'll agree. If that is your point, then 7 and 9 should be excluded
in favor of always using 11. So, that means any inconsitency in the EN and
the BCID should be ignored as long as the hash checks out. Just as long as
that is explicitly said.
So anyway, whats the harm in supporting 7 and 9 then? Would you say that
if an RP is presented with 7 and 9 you should always reject it,
regardless?
I think there has to be a dual notion of "support" here, one for issuers
and one for "verifiers", in sort of along the lines of "be conservative in
what you send and generous in what you receive". Perhaps, verifiers should
support 7,9,and 11, but issuers SHOULD only issue 11 in the cases where
ACs are tied to PKCs.
> > And as for 4 and 8, I would say 4 is preferable to 8, because, 8 can lead
> > to inconsistencies. Where only the public key matters (i.e. the holder of
> > the matching private key) it shouldn't matter what DN it has. If it does
> > matter, then it should hash the certificate that ties the DN to the key.
> > In SSL, if the AC is only concerned with the public key, then the DN may
> > yield an inconsistency. The user may have delivered PKC with his public key
> > but a different DN.
>
> I don't see how including hints that might help the RP find certs would
> hurt anything. If the user has presented a PKC whose subject name does
> not match the entityName but the public key matches the PK ODI, then
> there's no problem. The entityName is just a hint.
As long as that is explicitly stated in the document. So, in TLS if I am
delivered a PK certificate, I can ignore the EN and BCID from the AC
altoghether and just go for the PKC hash. However, I think there is
something in profile that states that the Entity Name MUST match the PK
certificate's subject DN.
Cheers,
-Polar
-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:polar@adiron.com 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com
Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08496 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 12:02:36 -0800 (PST)
Received: from speedy.rtfm.com ([198.144.203.243]) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id MAA21279; Thu, 2 Nov 2000 12:09:00 -0800 (PST)
Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by speedy.rtfm.com (8.9.1/8.6.4) with ESMTP id KAA11752; Thu, 2 Nov 2000 10:17:37 -0800 (PST)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id MAA22675; Thu, 2 Nov 2000 12:12:42 -0800 (PST)
Sender: ekr@rtfm.com
To: Steve Hanna <steve.hanna@sun.com>
Cc: Polar Humenn <polar@adiron.com>, "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
References: <Pine.LNX.4.10.10011021319280.143-100000@marcy.adiron.com> <3A01C58C.A8CD8CB8@sun.com>
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <ekr@rtfm.com>
Date: 02 Nov 2000 12:12:42 -0800
In-Reply-To: Steve Hanna's message of "Thu, 02 Nov 2000 14:50:36 -0500"
Message-ID: <kjaebiku9x.fsf@romeo.rtfm.com>
Lines: 30
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Steve Hanna <steve.hanna@sun.com> writes:
> Polar Humenn wrote:
> > On Thu, 2 Nov 2000, Steve Hanna wrote:
> > > The goal of the ac509prof draft is to define a profile of X.509
> > > attribute certificates for use with Internet protocols.
> >
> > Below you asked me for specific examples. So, can you please give me an a
> > definite list of which Internet protocols are supposed to support this
> > attribute certificate?
>
> ac509prof says "The profile places emphasis on attribute certificate
> support for Internet electronic mail, IPsec, and WWW security
> applications." So I expect that S/MIME, IPsec, and TLS would be the most
> important protocols for this profile.
TLS, at least, would need to be modified to use ACs. The issue is that
RFC 2246 explicitly specifies the order in which certificates must
appear:
certificate_list
This is a sequence (chain) of X.509v3 certificates. The sender's
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the
root certificate authority may optionally be omitted from the
chain, under the assumption that the remote end must already
possess it in order to validate it in any case.
-Ekr
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07751 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 11:46:16 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20981; Thu, 2 Nov 2000 12:52:39 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA07653; Thu, 2 Nov 2000 14:52:38 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA18648; Thu, 2 Nov 2000 14:52:37 -0500 (EST)
Message-ID: <3A01C58C.A8CD8CB8@sun.com>
Date: Thu, 02 Nov 2000 14:50:36 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <polar@adiron.com>
CC: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
References: <Pine.LNX.4.10.10011021319280.143-100000@marcy.adiron.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Polar Humenn wrote:
> On Thu, 2 Nov 2000, Steve Hanna wrote:
> > The goal of the ac509prof draft is to define a profile of X.509
> > attribute certificates for use with Internet protocols.
>
> Below you asked me for specific examples. So, can you please give me an a
> definite list of which Internet protocols are supposed to support this
> attribute certificate?
ac509prof says "The profile places emphasis on attribute certificate
support for Internet electronic mail, IPsec, and WWW security
applications." So I expect that S/MIME, IPsec, and TLS would be the most
important protocols for this profile.
> > As such, it is to be expected that we will make recommendations about
> > which features SHOULD or MUST be supported.
> >
> > It's unlikely that most implementors will want to support all 11 formats
> > listed above. If we can identify one or two formats that are sufficient
> > for use with Internet protocols and recommend that those formats be
> > supported, then we can increase the chances of successful
> > interoperation. If we make no such recommendations, it's unlikely that
> > we can achieve this.
>
> I understand that. But different applications and different protocols need
> different things.
Sure. If you can identify an important reason why one of these formats
is needed for the protocols of concern to us, then we should keep it.
Otherwise, we should not.
> > If it is crucial that a particular AC be used only in combination with a
> > particular PKC, then I have no objection to allowing format 11. However,
> > I would be more convinced if you had a specific example.
>
> I thought I just did.
Could you be more specific?
> > This would also allow us to support role specification certificates
> > (which assign privileges or attributes to a role). I realized after
> > sending my email that we cannot support them with formats 4-11, because
> > a role does not have a public key. And I suppose that we do want to
> > support them, since we discuss them in section 4.4.5.
>
> Well, that's problematic on how you define the role. A role also needs
> scoping information, like "who's role". Is a role defined by a DN?
The roleAuthority field defines the scope for a role.
> Option 11 is definitely preferable where PKCs are used. Options 7 and 9
> are desirable from a stand point of verifying the certificate being
> pointed to, i.e. in those Internet protocols where the RP must look up
> certificates.
Why would 7 (BCID & PKC ODI) or 9 (EN & PKC ODI) be preferable to 11
(BCID, EN, & PKC ODI) when the RP must look up certificates? I would
expect that 11 would indisputably be the best in this circumstance,
since it provides more hints to the RP.
> And as for 4 and 8, I would say 4 is preferable to 8, because, 8 can lead
> to inconsistencies. Where only the public key matters (i.e. the holder of
> the matching private key) it shouldn't matter what DN it has. If it does
> matter, then it should hash the certificate that ties the DN to the key.
> In SSL, if the AC is only concerned with the public key, then the DN may
> yield an inconsistency. The user may have delivered PKC with his public key
> but a different DN.
I don't see how including hints that might help the RP find certs would
hurt anything. If the user has presented a PKC whose subject name does
not match the entityName but the public key matches the PK ODI, then
there's no problem. The entityName is just a hint.
-Steve
Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06046 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 11:17:50 -0800 (PST)
Received: from certplus.com ([192.168.212.171]) by certplus.com (8.8.7/8.8.7) with ESMTP id UAA24378 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 20:30:07 +0100
Message-ID: <3A01BF34.B3723D9B@certplus.com>
Date: Thu, 02 Nov 2000 20:23:32 +0100
From: Jean-Marc Desperrier <jean-marc.desperrier@certplus.com>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <ietf-pkix@imc.org>
Subject: Extended Key Usage and path validation
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've been trying recently to understand how path validation should be
done for the usage of a key.
Until now, the only document that I've found that's really explicit is
the following from Netscape/iPlanet :
http://docs.iplanet.com/docs/manuals/cms/41/dep_gide/ext.htm
Netscape, in this document, says this about extended key usage in path
validation.
"A given certificate is valid only for the intersection of key usages of
all the certificates in the chain to its root (as determined by both the
Extended Key Usage extension for each certificate and the corresponding
user settings). To be valid for a particular usage, the end-entity
certificate and all certificates in the chain must all be valid for that
usage"
In fact, in the context it's not very clear whether this is what
Netscape recommends or the current practice of Microsoft softwares.
But their recommendation for certificat format in table B.1 of that
document is perfectly coherent with that.
This path validation does not apply to keyUsage.
A CA with a keyUsage of keyCertSign, cRLSign, can perfectly emit a valid
certificate with a keyUsage of digitalSignature.
I've been reading through RFC2459, and I was not able able to find
anything that really supports this behaviour.
Is this actually the intended use of key usage and extended key usage ?
For example Netscape recommends the following for a CA that signs S/MIME
client certificate :
extKeyUsage: Email
keyUsage: keyCertSign, cRLSign
But then extKeyUsage and keyUsage are not consistent each other.
After RFC2459, "extKeyUsage: Email" is consistent with digitalSignature,
but not with keyCertSign, cRLSign
RFC2459 says the certificate MUST only be used for a purpose consistant
with both fields and is invalid if none exist.
This only applies when both are flagged critical, but if the correct
setting of this values forbids you to set them critical, it sounds quite
annoying.
There should be an explicit table of what is compatible with what.
I'm afraid not every implementer of RFC2459 will make the same decision
of which values are compatible if trying to implement that with the
current text in RFC2459.txt or draft-ietf-pkix-new-part1-02.txt.
Now if extended key usage must not be used in path validation, then we
loose the possibility to constraint the usage of a certificate in the
CAs above it, except maybe through policy, but this is not something the
software can interpret as easily as extended key usage.
Should this way of using extKeyUsage be considered bad practice and
avoided or not ?
Isn't there the need for a PKIX document that would explicitely detail
how a complex CA path should be set for various uses ? (if there is one
that can effectively be used for that, I've missed it).
Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04007 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 10:58:09 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id OAA04863; Thu, 2 Nov 2000 14:00:06 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 2 Nov 2000 14:00:06 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: Steve Hanna <steve.hanna@sun.com>
cc: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
In-Reply-To: <3A01AB14.3D302818@sun.com>
Message-ID: <Pine.LNX.4.10.10011021319280.143-100000@marcy.adiron.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi Steve!
On Thu, 2 Nov 2000, Steve Hanna wrote:
<snip>
> The goal of the ac509prof draft is to define a profile of X.509
> attribute certificates for use with Internet protocols.
Below you asked me for specific examples. So, can you please give me an a
definite list of which Internet protocols are supposed to support this
attribute certificate?
> As such, it is to be expected that we will make recommendations about
> which features SHOULD or MUST be supported.
>
> It's unlikely that most implementors will want to support all 11 formats
> listed above. If we can identify one or two formats that are sufficient
> for use with Internet protocols and recommend that those formats be
> supported, then we can increase the chances of successful
> interoperation. If we make no such recommendations, it's unlikely that
> we can achieve this.
I understand that. But different applications and different protocols need
different things.
> > > Let's see if I can narrow things down a bit. I'll start by pointing out
> > > that using objectDigestInfo with publicKeyCert hash may cause problems
> > > if the holder wants to use a different PKC to authenticate than the one
> > > whose hash is in the AC.
> >
> > I would like to point out that the AC in this case is stating that
> > attributes are only valid for the particular "context" of the contained
> > public key, which is something I would hope could be enforced. It means
> > that I want you to use a certain PKC certificate, whether it be for
> > auditing or validation characteristics of signature, i.e. he must use the
> > key that was certified for transactions over $1,000,000,000,000,000
> > Turkish Lire and whatever else is in the certificate, such as the
> > particular DN, a particular Issuer, or some proprietary critical
> > identifying v3 attribute extension.
> >
> > I think that is certainly critical, because I can create my public key.
> > Getting it certified for use in several different contexts is a definite
> > plausibility.
> >
> > Remember the other two elements, entityName and baseCertificateID are only
> > "hints", as Sharon as stated, to finding the correct certificate. If the
> > Attribute Authority only certifies the publickey I can still fake PKCs and
> > Issuer PKCs with those names and serial numbers with the same public key,
> > with of course the ability to fool the relying party that those names
> > exist underneath alternate PKIs that it trusts.
> >
> > In the cases, such as SSL, where the certificates are actually delivered
> > by the client, he is stating a particular context for the authentication.
> > You may want the AC to make sure that he is using that context. (for
> > auditing, logging, non-repudiation, etc).
> >
> > I still see a need for this hash. However, I also agree that there are
> > cases where only the publicKey would matter and not the certificate.
>
> If it is crucial that a particular AC be used only in combination with a
> particular PKC, then I have no objection to allowing format 11. However,
> I would be more convinced if you had a specific example.
I thought I just did.
> > > So I suggest that we not recommend the use of
> > > formats 5, 7, 9, and 11 above.
> > >
> > > Is there any reason *not* to include a publicKey hash in the Holder?
> > > Perhaps the holder will want to use a different key than the one whose
> > > hash is in the AC. But that sounds unlikely to me. In that circumstance,
> > > they should probably get an AC for the second key. Getting a new AC
> > > should not be hard. So I suggest (somewhat contrary to my earlier
> > > comments) that our recommended format should include a publicKey hash.
> >
> > I'll certainly agree with that in cases where X.509 PKCs are used to
> > identify users. However, If you are certifying a Kerberos Name, or a
> > rfc822 name, you have to do some mucking around to make sure that the AC
> > is actually talking about the same party you believe. It's the same
> > problem with verifying just DNs (except that Kerberos and rfc822 are a bit
> > better as they include both entity and name path of issuers all the way to
> > its root). Including a KerberosTicket Hash is not quite right, although
> > conceivable. (something like that would bring the use of Kerberos'
> > blazingly fast authentication to a screaming halt with all the public key
> > signature validations that have to be performed).
>
> So you are arguing that we should support format 2 (entityName only),
> for cases where the holder doesn't have a public key (or where it's
> easier to authenticate them via some other mechanism)?
That would have to be if you want to support AC outside of PKI. I don't
have any specific examples.
> This would also allow us to support role specification certificates
> (which assign privileges or attributes to a role). I realized after
> sending my email that we cannot support them with formats 4-11, because
> a role does not have a public key. And I suppose that we do want to
> support them, since we discuss them in section 4.4.5.
Well, that's problematic on how you define the role. A role also needs
scoping information, like "who's role". Is a role defined by a DN?
> So we should recommend that AC verifiers support format 2 for this use
> case. Now we're up to three formats: 2 (where a name is the holder), 10
> (where a public key is the holder), and 11 (where a PKC is the holder).
> I hope that's all!
I think that was Tom Gindin's conclusion as well. which is:
[Tom Gindin] So I would recommend that RP's MUST support cases 2 and 11,
SHOULD support cases 7 and 9, and I'd poll the group on whether 4 is
better than 8 or not.
I would say that 2 should be supported in cases such that the naming
mechanism is unique to the application, i.e. Kerberos, RFC822, DN's only
where they can be considered verifiably unique (although I don't know how
that would be accomplished in the "interoperable" sense, due to the name
collision problem with DNs and their issuers).
Option 11 is definitely preferable where PKCs are used. Options 7 and 9
are desirable from a stand point of verifying the certificate being
pointed to, i.e. in those Internet protocols where the RP must look up
certificates.
And as for 4 and 8, I would say 4 is preferable to 8, because, 8 can lead
to inconsistencies. Where only the public key matters (i.e. the holder of
the matching private key) it shouldn't matter what DN it has. If it does
matter, then it should hash the certificate that ties the DN to the key.
In SSL, if the AC is only concerned with the public key, then the DN may
yield an inconsistency. The user may have delivered PKC with his public key
but a different DN.
Cheers,
-Polar
-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:polar@adiron.com 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01554 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 10:01:17 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02789; Thu, 2 Nov 2000 11:06:28 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA04918; Thu, 2 Nov 2000 13:04:34 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id NAA09367; Thu, 2 Nov 2000 13:04:33 -0500 (EST)
Message-ID: <3A01AC38.BB3ADE3E@sun.com>
Date: Thu, 02 Nov 2000 13:02:32 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Gindin/Watson/IBM <tgindin@us.ibm.com>
CC: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
References: <OF83AEE78E.1C97E924-ON8525698B.0054AC40@somers.hqregion.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Gindin/Watson/IBM wrote:
>
> My own recommendations would run almost opposite yours. In the
> extreme case, option 7 is clearly preferable to option 6 because both
> options specify a specific certificate (as does option 1), and option 7
> locks down the whole certificate while option 6 does not.
You assume that baseCertificateID specifies a particular PKC. When used
in combination with objectDigestInfo, it does not. It only specifies a
searching hint (as Sharon said). Other PKCs that meet the requirements
of the objectDigestInfo will suffice. So option 6 would work with any
PKC that has the specified public key. If this is desirable, option 6 is
superior to option 7. I see little argument for option 1 over option 7,
however. It specifies a particular PKC without the extra protection of a
hash.
> It is also
> clearly preferable to option 5, which specifies a single certificate
> without making it locatable.
Agreed. Option 5 is not very useful.
> A similar argument prefers option 11 to
> option 10 and option 3.
As described above, I don't agree that option 11 is necessarily superior
to option 10. However, I do agree that option 11 is superior to option
3.
So now we have reasons IMO to prefer 7 or 11 to 1,
> 3, 5, 6 or 10.
> This leaves 2, 4, 8, and 9. Case 2 is of independent value and should
> be permitted.
Yes, I agree (as noted in my recent email to Polar).
> Case 4 is somewhat debatable - its meaning is "I'll accept
> any unrevoked and unexpired certificate with this particular key" and case
> 8 is more secure, but case 4 permits a name change while 8 doesn't.
Actually, case 8 is no more secure. The entityName is only a hint (as
Sharon said). Formats 4, 6, 8, and 10 are equivalent from a security
standpoint.
> Case 9
> is a simplified case of 11 (as 7 also is) and is not particularly
> necessary.
Agreed.
> So I would recommend that RP's MUST support cases 2 and 11, SHOULD
> support cases 7 and 9, and I'd poll the group on whether 4 is better than 8
> or not.
Why support 7 and 9? If you have a PKC in hand, why not provide its
issuer name, serial number, and subject name as hints?
After my discussion with Polar, I'm leaning toward supporting 2, 10, and
11, so we're not so far apart, after all.
-Steve
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01049 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 09:55:09 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29235; Thu, 2 Nov 2000 11:01:31 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA03784; Thu, 2 Nov 2000 12:59:42 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id MAA09094; Thu, 2 Nov 2000 12:59:41 -0500 (EST)
Message-ID: <3A01AB14.3D302818@sun.com>
Date: Thu, 02 Nov 2000 12:57:40 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <polar@adiron.com>
CC: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
References: <Pine.LNX.4.10.10011021050150.143-100000@marcy.adiron.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Polar Humenn wrote:
> On Thu, 2 Nov 2000, Steve Hanna wrote:
> > We now have 11 possible formats for the Holder field:
> >
> > 1) baseCertificateID only
> > 2) entityName only
> > 3) baseCertificateID and entityName
> > 4) objectDigestInfo only with publicKey hash
> > 5) objectDigestInfo only with publicKeyCert hash
> > 6) baseCertificateID and objectDigestInfo with publicKey hash
> > 7) baseCertificateID and objectDigestInfo with publicKeyCert hash
> > 8) entityName and objectDigestInfo with publicKey hash
> > 9) entityName and objectDigestInfo with publicKeyCert hash
> > 10) baseCertificateID, entityName, and objectDigestInfo with publicKey
> > hash
> > 11) baseCertificateID, entityName, and objectDigestInfo with
> > publicKeyCert hash
> >
> > Given that we're designing a *profile* of X.509 ACs, can we choose one
> > or two of these formats, recommend that AC issuers only use those, and
> > require that AC verifiers be able to process them? If not, then I'm
> > afraid interoperability will be impossible.
>
> I don't see why not following X.509 isn't a good thing. And why would
> interoperability be impossible?
The goal of the ac509prof draft is to define a profile of X.509
attribute certificates for use with Internet protocols. As such, it is
to be expected that we will make recommendations about which features
SHOULD or MUST be supported.
It's unlikely that most implementors will want to support all 11 formats
listed above. If we can identify one or two formats that are sufficient
for use with Internet protocols and recommend that those formats be
supported, then we can increase the chances of successful
interoperation. If we make no such recommendations, it's unlikely that
we can achieve this.
> > Let's see if I can narrow things down a bit. I'll start by pointing out
> > that using objectDigestInfo with publicKeyCert hash may cause problems
> > if the holder wants to use a different PKC to authenticate than the one
> > whose hash is in the AC.
>
> I would like to point out that the AC in this case is stating that
> attributes are only valid for the particular "context" of the contained
> public key, which is something I would hope could be enforced. It means
> that I want you to use a certain PKC certificate, whether it be for
> auditing or validation characteristics of signature, i.e. he must use the
> key that was certified for transactions over $1,000,000,000,000,000
> Turkish Lire and whatever else is in the certificate, such as the
> particular DN, a particular Issuer, or some proprietary critical
> identifying v3 attribute extension.
>
> I think that is certainly critical, because I can create my public key.
> Getting it certified for use in several different contexts is a definite
> plausibility.
>
> Remember the other two elements, entityName and baseCertificateID are only
> "hints", as Sharon as stated, to finding the correct certificate. If the
> Attribute Authority only certifies the publickey I can still fake PKCs and
> Issuer PKCs with those names and serial numbers with the same public key,
> with of course the ability to fool the relying party that those names
> exist underneath alternate PKIs that it trusts.
>
> In the cases, such as SSL, where the certificates are actually delivered
> by the client, he is stating a particular context for the authentication.
> You may want the AC to make sure that he is using that context. (for
> auditing, logging, non-repudiation, etc).
>
> I still see a need for this hash. However, I also agree that there are
> cases where only the publicKey would matter and not the certificate.
If it is crucial that a particular AC be used only in combination with a
particular PKC, then I have no objection to allowing format 11. However,
I would be more convinced if you had a specific example.
> > So I suggest that we not recommend the use of
> > formats 5, 7, 9, and 11 above.
> >
> > Is there any reason *not* to include a publicKey hash in the Holder?
> > Perhaps the holder will want to use a different key than the one whose
> > hash is in the AC. But that sounds unlikely to me. In that circumstance,
> > they should probably get an AC for the second key. Getting a new AC
> > should not be hard. So I suggest (somewhat contrary to my earlier
> > comments) that our recommended format should include a publicKey hash.
>
> I'll certainly agree with that in cases where X.509 PKCs are used to
> identify users. However, If you are certifying a Kerberos Name, or a
> rfc822 name, you have to do some mucking around to make sure that the AC
> is actually talking about the same party you believe. It's the same
> problem with verifying just DNs (except that Kerberos and rfc822 are a bit
> better as they include both entity and name path of issuers all the way to
> its root). Including a KerberosTicket Hash is not quite right, although
> conceivable. (something like that would bring the use of Kerberos'
> blazingly fast authentication to a screaming halt with all the public key
> signature validations that have to be performed).
So you are arguing that we should support format 2 (entityName only),
for cases where the holder doesn't have a public key (or where it's
easier to authenticate them via some other mechanism)?
This would also allow us to support role specification certificates
(which assign privileges or attributes to a role). I realized after
sending my email that we cannot support them with formats 4-11, because
a role does not have a public key. And I suppose that we do want to
support them, since we discuss them in section 4.4.5.
So we should recommend that AC verifiers support format 2 for this use
case. Now we're up to three formats: 2 (where a name is the holder), 10
(where a public key is the holder), and 11 (where a PKC is the holder).
I hope that's all!
-Steve
Received: from jis.mit.edu (JIS.MIT.EDU [18.72.0.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28672 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 09:17:09 -0800 (PST)
Received: from localhost.localdomain (localhost [127.0.0.1]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA17918; Thu, 2 Nov 2000 12:23:18 -0500 (EST)
Received: (from jis@localhost) by localhost.localdomain (8.8.7/8.8.7) id MAA00584; Thu, 2 Nov 2000 12:23:17 -0500
Date: Thu, 2 Nov 2000 12:23:17 -0500
Message-Id: <200011021723.MAA00584@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: jis set sender to jis@mit.edu using -f
From: "Jeffrey I. Schiller" <jis@mit.edu>
To: ietf-pkix@imc.org
Cc: Marcus Leech <mleech@nortelnetworks.com>
Subject: draft-ietf-pkix-dcs-07.txt approved for an EXPERIMENTAL Document
-----BEGIN PGP SIGNED MESSAGE-----
The IESG has agreed to public Certification Server Protocols
<draft-ietf-pkix-dcs-07.txt> as an EXPERIMENTAL RFC.
The RFC Editor will be instructed to add the text:
"The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF
Executive Director."
to the document. I am not sure where it will be added, I suspect
either near the beginning or in Section 12 (Patents).
-Jeff
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Comment: Processed by Mailcrypt 3.5b6, an Emacs/PGP interface
Charset: noconv
iQCVAwUBOgGjBMUtR20Nv5BtAQGAhwP9EPTg16tewStABB6zReCbfQ7+Qpe0QcYq
xaYdgNPdDleIFoc2VMZDrXRFio3L/lRZNc8ROojuxrd4vqBYThSkWF9UKr9G5NRQ
8JX+Uk/kVfV9TIomVBPz59ztb+3o61zcwi+lRWOSQlxYanSr4nQt5bow1pIAVaJj
BZzq1lklXu0=
=2h01
-----END PGP SIGNATURE-----
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28433 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 09:15:47 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA253868; Thu, 2 Nov 2000 12:21:01 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id MAA18992; Thu, 2 Nov 2000 12:20:29 -0500
Importance: Normal
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
To: Steve Hanna <steve.hanna@sun.com>
Cc: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF83AEE78E.1C97E924-ON8525698B.0054AC40@somers.hqregion.ibm.com>
From: "Tom Gindin/Watson/IBM" <tgindin@us.ibm.com>
Date: Thu, 2 Nov 2000 12:21:11 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.5 |September 22, 2000) at 11/02/2000 12:21:22 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
My own recommendations would run almost opposite yours. In the
extreme case, option 7 is clearly preferable to option 6 because both
options specify a specific certificate (as does option 1), and option 7
locks down the whole certificate while option 6 does not. It is also
clearly preferable to option 5, which specifies a single certificate
without making it locatable. A similar argument prefers option 11 to
option 10 and option 3. So now we have reasons IMO to prefer 7 or 11 to 1,
3, 5, 6 or 10.
This leaves 2, 4, 8, and 9. Case 2 is of independent value and should
be permitted. Case 4 is somewhat debatable - its meaning is "I'll accept
any unrevoked and unexpired certificate with this particular key" and case
8 is more secure, but case 4 permits a name change while 8 doesn't. Case 9
is a simplified case of 11 (as 7 also is) and is not particularly
necessary.
So I would recommend that RP's MUST support cases 2 and 11, SHOULD
support cases 7 and 9, and I'd poll the group on whether 4 is better than 8
or not.
Tom Gindin
Steve Hanna <steve.hanna@sun.com> on 11/02/2000 09:50:45 AM
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
cc: ietf-pkix@imc.org
Subject: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
We now have 11 possible formats for the Holder field:
1) baseCertificateID only
2) entityName only
3) baseCertificateID and entityName
4) objectDigestInfo only with publicKey hash
5) objectDigestInfo only with publicKeyCert hash
6) baseCertificateID and objectDigestInfo with publicKey hash
7) baseCertificateID and objectDigestInfo with publicKeyCert hash
8) entityName and objectDigestInfo with publicKey hash
9) entityName and objectDigestInfo with publicKeyCert hash
10) baseCertificateID, entityName, and objectDigestInfo with publicKey
hash
11) baseCertificateID, entityName, and objectDigestInfo with
publicKeyCert hash
Given that we're designing a *profile* of X.509 ACs, can we choose one
or two of these formats, recommend that AC issuers only use those, and
require that AC verifiers be able to process them? If not, then I'm
afraid interoperability will be impossible.
Let's see if I can narrow things down a bit. I'll start by pointing out
that using objectDigestInfo with publicKeyCert hash may cause problems
if the holder wants to use a different PKC to authenticate than the one
whose hash is in the AC. Using objectDigestInfo with publicKey hash
should resolve the concern raised by Polar (problems with inconsistent
or duplicative naming). So I suggest that we not recommend the use of
formats 5, 7, 9, and 11 above.
Is there any reason *not* to include a publicKey hash in the Holder?
Perhaps the holder will want to use a different key than the one whose
hash is in the AC. But that sounds unlikely to me. In that circumstance,
they should probably get an AC for the second key. Getting a new AC
should not be hard. So I suggest (somewhat contrary to my earlier
comments) that our recommended format should include a publicKey hash.
According to Sharon, if we include objectDigestInfo in any form,
baseCertificateID and entityName are only hints to be used for searching
purposes. So is there any reason not to include them? If not, I suggest
that we recommend that AC issuers use format 10 above. And that we
require that AC verifiers support that format. Support for other formats
would be optional. This should simplify things substantially for
implementors without substantial loss of functionality.
Have I missed anything?
-Steve
"David P. Kemp" wrote:
>
> Sharon,
>
> Thanks for clarifying the distinction between the "controlling" Holder
> option and other options used only as search aids. That's what I get
> for reading the AC profile without being thoroughly familiar with the
> base X.509 document :-(.
>
> I agree that the precedence shown below is correct, and withdraw my
> suggestion for mutual exclusion between entityName and the other
> options.
>
> Dave
>
> > From: Sharon Boeyen <sharon.boeyen@entrust.com>
> > To: "'Steve Hanna'" <steve.hanna@sun.com>
> > Cc: ietf-pkix@imc.org
> > Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> > Date: Fri, 27 Oct 2000 15:51:34 -0400
> >
> > Yep I can explain - the second text is not text from the standard, but
my
> > explanation of what I believe is intended and you are correct that in
the
> > Holder, the order is not as I indicated (it is in issuer though and
that's
> > where the confusion krept in). What I meant specifically was:
> >
> > - if entityName and baseCertificateID are present, then ONLY
baseCertificateID
> > may be used and entityName is a potentially helpful search tool
> > - if entityName and objectDigestInfo are present, then ONLY
objectDigestInfo may
> > be used and entityName is a potentially helpful search tool
> > - if baseCertificateID and objectDigestInfo are present, then ONLY
objectDigestInfo
> > may be used and baseCertificateID is a potentially helpful search
tool
> >
> > - if entityName, baseCertificateID and objectDigestInfo are present,
the ONLY
> > objectDigestInfo may be used and entityName and baseCertificateID are
potentially
> > helpful search tools.
> >
> > Sorry for the confusion and thanks for catching it. I shouldn't have
> > tried to lump it all together.
> >
> > Sharon
Received: from jis.mit.edu (JIS.MIT.EDU [18.72.0.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27169 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 08:56:47 -0800 (PST)
Received: from localhost.localdomain (localhost [127.0.0.1]) by jis.mit.edu (8.9.1b+Sun/8.9.3) with ESMTP id MAA17747; Thu, 2 Nov 2000 12:00:19 -0500 (EST)
Received: (from jis@localhost) by localhost.localdomain (8.8.7/8.8.7) id MAA00577; Thu, 2 Nov 2000 12:00:13 -0500
Date: Thu, 2 Nov 2000 12:00:13 -0500
Message-Id: <200011021700.MAA00577@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: jis set sender to jis@mit.edu using -f
From: "Jeffrey I. Schiller" <jis@mit.edu>
To: Stefan Santesson <stefans@addtrust.com>
In-reply-to: <5.0.0.25.2.20001031092226.026a8bf0@mail.addtrust.com> (message from Stefan Santesson on Tue, 31 Oct 2000 09:25:19 +0100)
Subject: QC Document just passed the IESG
Cc: Stephen Kent <kent@bbn.com>, Tim Polk <wpolk@nist.gov>, Marcus Leech <mleech@nortelnetworks.com>, ietf-pkix@imc.org
-----BEGIN PGP SIGNED MESSAGE-----
The Qualified Certificates document <draft-ietf-pkix-qc-06.txt> just
passed during the IESG teleconference (within the last 5 minutes).
-Jeff
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Comment: Processed by Mailcrypt 3.5b6, an Emacs/PGP interface
Charset: noconv
iQCVAwUBOgGdmcUtR20Nv5BtAQG+zQP/epO7LyN3RezUBhFK805+3Jnb/aQoXmHM
0rOHGz3TgUzbrcU5gRG1psA6vb0eZy6M/mbWY4jfWAtNk4850xFAZ9tDTsRYRmBD
PpMxDiOHfRqyiCdib802EmdUAtU8h8CLhOpbwDxCSA5FSrXs0DoBglj67f9B5+5q
QPD2Hhv11Hw=
=6y33
-----END PGP SIGNATURE-----
Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27141 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 08:56:40 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id LAA04642; Thu, 2 Nov 2000 11:58:19 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 2 Nov 2000 11:58:18 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: Steve Hanna <steve.hanna@sun.com>
cc: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
In-Reply-To: <3A017F45.7E34DE77@sun.com>
Message-ID: <Pine.LNX.4.10.10011021050150.143-100000@marcy.adiron.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi Steve,
Comments below.
On Thu, 2 Nov 2000, Steve Hanna wrote:
> We now have 11 possible formats for the Holder field:
>
> 1) baseCertificateID only
> 2) entityName only
> 3) baseCertificateID and entityName
> 4) objectDigestInfo only with publicKey hash
> 5) objectDigestInfo only with publicKeyCert hash
> 6) baseCertificateID and objectDigestInfo with publicKey hash
> 7) baseCertificateID and objectDigestInfo with publicKeyCert hash
> 8) entityName and objectDigestInfo with publicKey hash
> 9) entityName and objectDigestInfo with publicKeyCert hash
> 10) baseCertificateID, entityName, and objectDigestInfo with publicKey
> hash
> 11) baseCertificateID, entityName, and objectDigestInfo with
> publicKeyCert hash
>
> Given that we're designing a *profile* of X.509 ACs, can we choose one
> or two of these formats, recommend that AC issuers only use those, and
> require that AC verifiers be able to process them? If not, then I'm
> afraid interoperability will be impossible.
I don't see why not following X.509 isn't a good thing. And why would
interoperability be impossible?
> Let's see if I can narrow things down a bit. I'll start by pointing out
> that using objectDigestInfo with publicKeyCert hash may cause problems
> if the holder wants to use a different PKC to authenticate than the one
> whose hash is in the AC.
I would like to point out that the AC in this case is stating that
attributes are only valid for the particular "context" of the contained
public key, which is something I would hope could be enforced. It means
that I want you to use a certain PKC certificate, whether it be for
auditing or validation characteristics of signature, i.e. he must use the
key that was certified for transactions over $1,000,000,000,000,000
Turkish Lire and whatever else is in the certificate, such as the
particular DN, a particular Issuer, or some proprietary critical
identifying v3 attribute extension.
I think that is certainly critical, because I can create my public key.
Getting it certified for use in several different contexts is a definite
plausibility.
Remember the other two elements, entityName and baseCertificateID are only
"hints", as Sharon as stated, to finding the correct certificate. If the
Attribute Authority only certifies the publickey I can still fake PKCs and
Issuer PKCs with those names and serial numbers with the same public key,
with of course the ability to fool the relying party that those names
exist underneath alternate PKIs that it trusts.
In the cases, such as SSL, where the certificates are actually delivered
by the client, he is stating a particular context for the authentication.
You may want the AC to make sure that he is using that context. (for
auditing, logging, non-repudiation, etc).
I still see a need for this hash. However, I also agree that there are
cases where only the publicKey would matter and not the certificate.
> Using objectDigestInfo with publicKey hash
> should resolve the concern raised by Polar (problems with inconsistent
> or duplicative naming).
That it should. :)
> So I suggest that we not recommend the use of
> formats 5, 7, 9, and 11 above.
>
> Is there any reason *not* to include a publicKey hash in the Holder?
> Perhaps the holder will want to use a different key than the one whose
> hash is in the AC. But that sounds unlikely to me. In that circumstance,
> they should probably get an AC for the second key. Getting a new AC
> should not be hard. So I suggest (somewhat contrary to my earlier
> comments) that our recommended format should include a publicKey hash.
I'll certainly agree with that in cases where X.509 PKCs are used to
identify users. However, If you are certifying a Kerberos Name, or a
rfc822 name, you have to do some mucking around to make sure that the AC
is actually talking about the same party you believe. It's the same
problem with verifying just DNs (except that Kerberos and rfc822 are a bit
better as they include both entity and name path of issuers all the way to
its root). Including a KerberosTicket Hash is not quite right, although
conceivable. (something like that would bring the use of Kerberos'
blazingly fast authentication to a screaming halt with all the public key
signature validations that have to be performed).
> According to Sharon, if we include objectDigestInfo in any form,
> baseCertificateID and entityName are only hints to be used for searching
> purposes. So is there any reason not to include them? If not, I suggest
> that we recommend that AC issuers use format 10 above. And that we
> require that AC verifiers support that format. Support for other formats
> would be optional. This should simplify things substantially for
> implementors without substantial loss of functionality.
>
> Have I missed anything?
No, I don't think you have. However, now the only problem I have is what
is the definition of "interoperability"? Or I should say what is the scope
of "interoperability" with respect to users, attribute certificate
issuers, and relying parties.
If you constrain the definition that all three must subscribe to the same
"trusted" LDAP directory or PKI then some of these lesser options, i.e.
anything without an objectDigestInfo, can start taking hold.
Cheers,
-Polar
> -Steve
>
> "David P. Kemp" wrote:
> >
> > Sharon,
> >
> > Thanks for clarifying the distinction between the "controlling" Holder
> > option and other options used only as search aids. That's what I get
> > for reading the AC profile without being thoroughly familiar with the
> > base X.509 document :-(.
> >
> > I agree that the precedence shown below is correct, and withdraw my
> > suggestion for mutual exclusion between entityName and the other
> > options.
> >
> > Dave
> >
> > > From: Sharon Boeyen <sharon.boeyen@entrust.com>
> > > To: "'Steve Hanna'" <steve.hanna@sun.com>
> > > Cc: ietf-pkix@imc.org
> > > Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> > > Date: Fri, 27 Oct 2000 15:51:34 -0400
> > >
> > > Yep I can explain - the second text is not text from the standard, but my
> > > explanation of what I believe is intended and you are correct that in the
> > > Holder, the order is not as I indicated (it is in issuer though and that's
> > > where the confusion krept in). What I meant specifically was:
> > >
> > > - if entityName and baseCertificateID are present, then ONLY baseCertificateID
> > > may be used and entityName is a potentially helpful search tool
> > > - if entityName and objectDigestInfo are present, then ONLY objectDigestInfo may
> > > be used and entityName is a potentially helpful search tool
> > > - if baseCertificateID and objectDigestInfo are present, then ONLY objectDigestInfo
> > > may be used and baseCertificateID is a potentially helpful search tool
> > >
> > > - if entityName, baseCertificateID and objectDigestInfo are present, the ONLY
> > > objectDigestInfo may be used and entityName and baseCertificateID are potentially
> > > helpful search tools.
> > >
> > > Sorry for the confusion and thanks for catching it. I shouldn't have
> > > tried to lump it all together.
> > >
> > > Sharon
>
-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:polar@adiron.com 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14800 for <ietf-pkix@imc.org>; Thu, 2 Nov 2000 06:51:29 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA13532; Thu, 2 Nov 2000 06:52:47 -0800 (PST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA22731; Thu, 2 Nov 2000 09:52:46 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id JAA24395; Thu, 2 Nov 2000 09:52:46 -0500 (EST)
Message-ID: <3A017F45.7E34DE77@sun.com>
Date: Thu, 02 Nov 2000 09:50:45 -0500
From: Steve Hanna <steve.hanna@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
CC: ietf-pkix@imc.org
Subject: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
References: <200010312132.QAA28047@roadblock.missi.ncsc.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
We now have 11 possible formats for the Holder field:
1) baseCertificateID only
2) entityName only
3) baseCertificateID and entityName
4) objectDigestInfo only with publicKey hash
5) objectDigestInfo only with publicKeyCert hash
6) baseCertificateID and objectDigestInfo with publicKey hash
7) baseCertificateID and objectDigestInfo with publicKeyCert hash
8) entityName and objectDigestInfo with publicKey hash
9) entityName and objectDigestInfo with publicKeyCert hash
10) baseCertificateID, entityName, and objectDigestInfo with publicKey
hash
11) baseCertificateID, entityName, and objectDigestInfo with
publicKeyCert hash
Given that we're designing a *profile* of X.509 ACs, can we choose one
or two of these formats, recommend that AC issuers only use those, and
require that AC verifiers be able to process them? If not, then I'm
afraid interoperability will be impossible.
Let's see if I can narrow things down a bit. I'll start by pointing out
that using objectDigestInfo with publicKeyCert hash may cause problems
if the holder wants to use a different PKC to authenticate than the one
whose hash is in the AC. Using objectDigestInfo with publicKey hash
should resolve the concern raised by Polar (problems with inconsistent
or duplicative naming). So I suggest that we not recommend the use of
formats 5, 7, 9, and 11 above.
Is there any reason *not* to include a publicKey hash in the Holder?
Perhaps the holder will want to use a different key than the one whose
hash is in the AC. But that sounds unlikely to me. In that circumstance,
they should probably get an AC for the second key. Getting a new AC
should not be hard. So I suggest (somewhat contrary to my earlier
comments) that our recommended format should include a publicKey hash.
According to Sharon, if we include objectDigestInfo in any form,
baseCertificateID and entityName are only hints to be used for searching
purposes. So is there any reason not to include them? If not, I suggest
that we recommend that AC issuers use format 10 above. And that we
require that AC verifiers support that format. Support for other formats
would be optional. This should simplify things substantially for
implementors without substantial loss of functionality.
Have I missed anything?
-Steve
"David P. Kemp" wrote:
>
> Sharon,
>
> Thanks for clarifying the distinction between the "controlling" Holder
> option and other options used only as search aids. That's what I get
> for reading the AC profile without being thoroughly familiar with the
> base X.509 document :-(.
>
> I agree that the precedence shown below is correct, and withdraw my
> suggestion for mutual exclusion between entityName and the other
> options.
>
> Dave
>
> > From: Sharon Boeyen <sharon.boeyen@entrust.com>
> > To: "'Steve Hanna'" <steve.hanna@sun.com>
> > Cc: ietf-pkix@imc.org
> > Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> > Date: Fri, 27 Oct 2000 15:51:34 -0400
> >
> > Yep I can explain - the second text is not text from the standard, but my
> > explanation of what I believe is intended and you are correct that in the
> > Holder, the order is not as I indicated (it is in issuer though and that's
> > where the confusion krept in). What I meant specifically was:
> >
> > - if entityName and baseCertificateID are present, then ONLY baseCertificateID
> > may be used and entityName is a potentially helpful search tool
> > - if entityName and objectDigestInfo are present, then ONLY objectDigestInfo may
> > be used and entityName is a potentially helpful search tool
> > - if baseCertificateID and objectDigestInfo are present, then ONLY objectDigestInfo
> > may be used and baseCertificateID is a potentially helpful search tool
> >
> > - if entityName, baseCertificateID and objectDigestInfo are present, the ONLY
> > objectDigestInfo may be used and entityName and baseCertificateID are potentially
> > helpful search tools.
> >
> > Sorry for the confusion and thanks for catching it. I shouldn't have
> > tried to lump it all together.
> >
> > Sharon