RE: Web-PKI Keygen/Certreq Questions

[Pierre Heuze <[e-mail]>]

Anders Rundgren wrote:
>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>for performing key generation or performing certificate requests.
Indeed there isn't a de-facto reference for this, by now you must realize
every PKI/Browser vendors have developed their ownn solution as mentionned
already, but don't forget the many token/smart card providers who also have
come-up with additional solutions. So it's the jungle out there, as any
request in a search engine for "browser certificate request" or similar will
show (cf Stephen's comment do some more homework.)

Stephen Kent wrote:
> both browsers have had facilities for generating an RSA key pair for 
> a user, and sending a cert request for years.
Indeed, at least 1998 from my own experience, but surely someone will claim
an earlier date. In practice, it is almost always based on free/liberal use
of PKCS#10; which has raised many interop issues as you all know, to mention
few (signature and extension format).

Jean-Marc Desperrier wrote:
>So, from the point of view of what should be put on a web page to get a 
>browser to generate a certificate request, there is no standard.
>This can be considered not to be a valable item of concern for pkix
thought.
Indeed this topic is somewhat out of the scope of PKIX, but few things to
consider:
- Requesting a certificate is one of the most basic operation to be
completed in the PKI world and browser based application have gained a large
acceptance. So it is a valid concern.
- Requesting a certificate is a somewhat complex operation, and the
browser-based solution too often overlooked basic consideration for the sake
of simplicity, the main drawbacks are:
	- No authentication, Proof of Possession (having the key pair) is
often taken as valid  
        authentication mechanism (sic).
      - No standard way to mandate what certificate profile should be used
to fulfil the request
      - No control of the certificate life-cycle, each request are handled
separately which 
        doesn't cater well when certificate need to be renewed, or
re-activated 
        after suspension.
The above points are in part covered by various PKIX message format, but to
be honest they haven't gained acceptance (yet?) for browser based operations
and if used they are highly not interoperable (i.e. to say the least no
improvement on the interop side compare to using PKCS#10). 

So is it the case that one should refine the standard to restrict the use of
existing messages to cover the above scenario as to achieve greater
interoperability and hence acceptance? To me this seems to be a genuine item
for the PKIX group.

Pierre Heuzé
http://www.cardbase.com


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: 31 October 2003 19:35
To: Jean-Marc Desperrier
Cc: [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions



At 19:15 +0100 10/31/03, Jean-Marc Desperrier wrote:
>Stephen Kent wrote:
>
>>At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>>
>>>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>>>for performing key generation or performing certificate requests.
>>
>>yes, you are wrong.
>>
>>both browsers have had facilities for generating an RSA key pair 
>>for a user, and sending a cert request for years.
>
>Facilities is one thing, interoperability is another.

I have not worked this problem recently, but in my  experience 
developing three different CA products a few years ago, all were able 
to accept enrollment requests from both browsers, and all major 
providers of CA software did so as well. it was a necessary 
prerequisite for selling CA software.

we now have 2 PKIX standards for enrollment protocols: CMP and CMC. 
if the browser vendors choose to support these, then we have 
interoperable solutions as well, but vendors must choose to make use 
of them.

Steve


CardBASE Technologies® 
Address: BIM House, Crofton Road, Dun Laoghaire, Co Dublin, Ireland 
PH: [phone]  FAX: [phone]  WEB: http://www.cardbase.com 
 *********************************************************************** 
This e-mail and any attachment, contains information which is private 
and confidential and is intended for the addressee only. If you are not 
an addressee, you are not authorised to read, copy or use the e-mail 
or any attachments. If you have received this e-mail in error, please 
notify the sender by return e-mail and then destroy it. 
This message has been swept for viruses by anti-virus software. 
*********************************************************************** 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VNTQkT012426 for <[e-mail]>; Fri, 31 Oct 2003 15:29:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VNTQTg012425 for ietf-pkix-bks; Fri, 31 Oct 2003 15:29:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9VNTOkT012411 for <[e-mail]>; Fri, 31 Oct 2003 15:29:25 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 88997 messnum 279019 invoked from network[195.7.52.230/unknown]); 31 Oct 2003 23:29:21 -0000
Received: from unknown (HELO mailer.cardbase.com) (195.7.52.230) by mail02.svc.cra.dublin.eircom.net (qp 88997) with SMTP; 31 Oct 2003 23:29:21 -0000
Received: by mailer.cardbase.com with Internet Mail Service (5.5.2655.55) id <WADHR5L3>; Fri, 31 Oct 2003 23:29:40 -0000
Message-ID: <DF2205440160D511B877000255745FF24911B5@TMAIL>
From: Pierre Heuze <[e-mail]>
To: Stephen Kent <[e-mail]>, Jean-Marc Desperrier <[e-mail]>
Cc: [e-mail]
Subject: RE: Web-PKI Keygen/Certreq Questions
Date: Fri, 31 Oct 2003 23:29:29 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9VNTPkT012421
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>for performing key generation or performing certificate requests.
Indeed there isn't a de-facto reference for this, by now you must realize
every PKI/Browser vendors have developed their ownn solution as mentionned
already, but don't forget the many token/smart card providers who also have
come-up with additional solutions. So it's the jungle out there, as any
request in a search engine for "browser certificate request" or similar will
show (cf Stephen's comment do some more homework.)

Stephen Kent wrote:
> both browsers have had facilities for generating an RSA key pair for 
> a user, and sending a cert request for years.
Indeed, at least 1998 from my own experience, but surely someone will claim
an earlier date. In practice, it is almost always based on free/liberal use
of PKCS#10; which has raised many interop issues as you all know, to mention
few (signature and extension format).

Jean-Marc Desperrier wrote:
>So, from the point of view of what should be put on a web page to get a 
>browser to generate a certificate request, there is no standard.
>This can be considered not to be a valable item of concern for pkix
thought.
Indeed this topic is somewhat out of the scope of PKIX, but few things to
consider:
- Requesting a certificate is one of the most basic operation to be
completed in the PKI world and browser based application have gained a large
acceptance. So it is a valid concern.
- Requesting a certificate is a somewhat complex operation, and the
browser-based solution too often overlooked basic consideration for the sake
of simplicity, the main drawbacks are:
	- No authentication, Proof of Possession (having the key pair) is
often taken as valid  
        authentication mechanism (sic).
      - No standard way to mandate what certificate profile should be used
to fulfil the request
      - No control of the certificate life-cycle, each request are handled
separately which 
        doesn't cater well when certificate need to be renewed, or
re-activated 
        after suspension.
The above points are in part covered by various PKIX message format, but to
be honest they haven't gained acceptance (yet?) for browser based operations
and if used they are highly not interoperable (i.e. to say the least no
improvement on the interop side compare to using PKCS#10). 

So is it the case that one should refine the standard to restrict the use of
existing messages to cover the above scenario as to achieve greater
interoperability and hence acceptance? To me this seems to be a genuine item
for the PKIX group.

Pierre Heuzé
http://www.cardbase.com


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: 31 October 2003 19:35
To: Jean-Marc Desperrier
Cc: [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions



At 19:15 +0100 10/31/03, Jean-Marc Desperrier wrote:
>Stephen Kent wrote:
>
>>At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>>
>>>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>>>for performing key generation or performing certificate requests.
>>
>>yes, you are wrong.
>>
>>both browsers have had facilities for generating an RSA key pair 
>>for a user, and sending a cert request for years.
>
>Facilities is one thing, interoperability is another.

I have not worked this problem recently, but in my  experience 
developing three different CA products a few years ago, all were able 
to accept enrollment requests from both browsers, and all major 
providers of CA software did so as well. it was a necessary 
prerequisite for selling CA software.

we now have 2 PKIX standards for enrollment protocols: CMP and CMC. 
if the browser vendors choose to support these, then we have 
interoperable solutions as well, but vendors must choose to make use 
of them.

Steve


CardBASE Technologies® 
Address: BIM House, Crofton Road, Dun Laoghaire, Co Dublin, Ireland 
PH: [phone]  FAX: [phone]  WEB: http://www.cardbase.com 
 *********************************************************************** 
This e-mail and any attachment, contains information which is private 
and confidential and is intended for the addressee only. If you are not 
an addressee, you are not authorised to read, copy or use the e-mail 
or any attachments. If you have received this e-mail in error, please 
notify the sender by return e-mail and then destroy it. 
This message has been swept for viruses by anti-virus software. 
*********************************************************************** 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLt0kT009824 for <[e-mail]>; Fri, 31 Oct 2003 13:55:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VLt0E1009822 for ietf-pkix-bks; Fri, 31 Oct 2003 13:55:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VLsxkT009814 for <[e-mail]>; Fri, 31 Oct 2003 13:54:59 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t9o913p29.telia.com [213.64.27.29]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id h9VLslnw018759; Fri, 31 Oct 2003 22:54:47 +0100 (CET)
Message-ID: <003001c39ff9$2b78b570$1d1b40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <00e101c39fc2$a59fa200$3a1b40d5@arport> <p06002003bbc83730f4f9@[128.89.89.75]> <[e-mail]> <p0600200bbbc8676a42ac@[128.89.89.75]>
Subject: Re: Web-PKI Keygen/Certreq Questions
Date: Fri, 31 Oct 2003 22:51:40 +0100
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>Facilities is one thing, interoperability is another.

Thanx Jean Marc!

>I have not worked this problem recently, but in my  experience 
>developing three different CA products a few years ago, all were able 
>to accept enrollment requests from both browsers, and all major 
>providers of CA software did so as well. it was a necessary 
>prerequisite for selling CA software.

Sure, we all know that.  But with mobile internet we get a
set of new browsers and you must recognize them as well.

Also, I do no think that the key-gen facilities are indentical and
maybe, maybe these functions aren't even that fit for the purpose.
Otherwise I don't see why most new implementation of serious
Web-PKI bypass the whole thing.  One limitation I'm almost sure
of: You cannot generate multiple keys in one step.
Other likely limitations include CA-control of password
policy, and getting key container signatures (figuring out
its "quality" and tying it to a "device")

>we now have 2 PKIX standards for enrollment protocols: CMP and CMC. 
>if the browser vendors choose to support these, then we have 
>interoperable solutions as well, but vendors must choose to make use 
>of them.

But none of these define a browser interface beyond MIME type
which render these protocols incomplete (in this context nota bene).

As far as I can see Web-PKI (pretty much all aspects of it), is in
a really lousy shape and desperately needs a blood transfusion.
Particularly as it will have a couple of billion users within
five years or so.

Anders


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJdqkT003971 for <[e-mail]>; Fri, 31 Oct 2003 11:39:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJdqfm003970 for ietf-pkix-bks; Fri, 31 Oct 2003 11:39:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJdpkT003964 for <[e-mail]>; Fri, 31 Oct 2003 11:39:51 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h9VJdklo007502; Fri, 31 Oct 2003 14:39:46 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0600200bbbc8676a42ac@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <00e101c39fc2$a59fa200$3a1b40d5@arport> <p06002003bbc83730f4f9@[128.89.89.75]> <[e-mail]>
Date: Fri, 31 Oct 2003 14:34:38 -0500
To: Jean-Marc Desperrier <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Web-PKI Keygen/Certreq Questions
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 19:15 +0100 10/31/03, Jean-Marc Desperrier wrote:
>Stephen Kent wrote:
>
>>At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>>
>>>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>>>for performing key generation or performing certificate requests.
>>
>>yes, you are wrong.
>>
>>both browsers have had facilities for generating an RSA key pair 
>>for a user, and sending a cert request for years.
>
>Facilities is one thing, interoperability is another.

I have not worked this problem recently, but in my  experience 
developing three different CA products a few years ago, all were able 
to accept enrollment requests from both browsers, and all major 
providers of CA software did so as well. it was a necessary 
prerequisite for selling CA software.

we now have 2 PKIX standards for enrollment protocols: CMP and CMC. 
if the browser vendors choose to support these, then we have 
interoperable solutions as well, but vendors must choose to make use 
of them.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIEvkT000997 for <[e-mail]>; Fri, 31 Oct 2003 10:14:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIEvnS000996 for ietf-pkix-bks; Fri, 31 Oct 2003 10:14:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft2.fr.colt.net (smtp-ft2.fr.colt.net [213.41.78.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIEtkT000990 for <[e-mail]>; Fri, 31 Oct 2003 10:14:55 -0800 (PST) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft2.fr.colt.net with ESMTP id h9VIEpD29861 for <[e-mail]>; Fri, 31 Oct 2003 19:14:51 +0100
Message-ID: <[e-mail]>
Date: Fri, 31 Oct 2003 19:15:27 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031004
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Web-PKI Keygen/Certreq Questions
References: <00e101c39fc2$a59fa200$3a1b40d5@arport> <p06002003bbc83730f4f9@[128.89.89.75]>
In-Reply-To: <p06002003bbc83730f4f9@[128.89.89.75]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

> At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>
>> I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>> for performing key generation or performing certificate requests.
>
> yes, you are wrong.
>
> both browsers have had facilities for generating an RSA key pair for a 
> user, and sending a cert request for years.

Facilities is one thing, interoperability is another.

IE does fully rely on the page interacting with the proprietary xenroll 
to generate request.
Some people that were unhappy with some aspect of the behaviours of 
xenroll have even developped their own solution.

Netscape was using a propretary, little documented HTML tag to generate 
a request in the 4.x browser, KEYGEN.

Newer Mozilla and Netscape continue to support this, but can also use a 
significantly less ugly javascript-based solution with a call to the 
*generateCRMFRequest*() function .

So, from the point of view of what should be put on a web page to get a 
browser to generate a certificate request, there is no standard.
This can be considered not to be a valable item of concern for pkix thought.

Even the format of the request, which is much more of concern to pkix, 
is not fully standardised, because if IE was generating pkcs#10, the 
KEYGEN would create a netscape specific SPKAC format.
As can be guessed from the name, newer Netscape can generate a CRMF 
format request.
But I don't know if the idea of sending it raw without any CMC/CMP 
envelop makes it a very compatible solution.
Newer xenroll can generate CMC format request.
But it's not as standard-based as it may seem, because xenroll will 
always put a pkcs#10 inside, and never ever a crmf.
This even if the request include functionnalities that require a CRMF 
based CMC request, like private key exportation for key recovery.
There's probably few people outside of Microsoft who understand how the 
key is exported in this case, the solution used does not conform to any 
standard and has some platform specific elements.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VG4rkT096083 for <[e-mail]>; Fri, 31 Oct 2003 08:04:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VG4rvg096082 for ietf-pkix-bks; Fri, 31 Oct 2003 08:04:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VG4pkT096076 for <[e-mail]>; Fri, 31 Oct 2003 08:04:51 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h9VG4llo024065; Fri, 31 Oct 2003 11:04:47 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002003bbc83730f4f9@[128.89.89.75]>
In-Reply-To: <00e101c39fc2$a59fa200$3a1b40d5@arport>
References: <00e101c39fc2$a59fa200$3a1b40d5@arport>
Date: Fri, 31 Oct 2003 10:59:54 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Web-PKI Keygen/Certreq Questions
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>Dear List,
>
>After verifying that Web-signing is indeed both a much wanted
>thing, as well as being in a miserable state standards-wise, I took
>the liberty to check out another piece in the Web-PKI puzzle:
>
>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>for performing key generation or performing certificate requests.
>This may be due to a limited effort on my part, but I suspect this
>is just another "black hole" with respect to interoperability.
>Please tell me I'm wrong!

yes, you are wrong.

both browsers have had facilities for generating an RSA key pair for 
a user, and sending a cert request for years.

do some more homework.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFlCkT095346 for <[e-mail]>; Fri, 31 Oct 2003 07:47:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VFlCnc095345 for ietf-pkix-bks; Fri, 31 Oct 2003 07:47:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFl9kT095338 for <[e-mail]>; Fri, 31 Oct 2003 07:47:10 -0800 (PST) (envelope-from [e-mail])
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h9VFkd0U018151 for <[e-mail]>; Fri, 31 Oct 2003 10:46:39 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 31 Oct 2003 10:46:22 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Draft PKIX Agenda for 58th IETF
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I have appended a draft agenda.  Okay, so I didn't meet my goal of 
Monday....sigh.

As Peter Sylvester pointed out to me, *that's* why the U.S. Men can't win 
the World Cup.  We keep missing the goal.  That means I come by it 
honestly, right?

Thanks!

Tim

[P.S.  If I was true to form, I will have missed at least one agenda 
request in my mail box.  If that is you, please let me know ASAP so I can 
correct it.]

------------------------------------------------------------------------------------------------------------

PKIX WG (pkix-wg)


MONDAY, November 10, 2003 1530-1730

=================================


CHAIR Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>


AGENDA


1. WG Status and Direction


1.1 Document Status Review [Tim Polk (NIST)]


       The working group has a number of Internet-Drafts.  Many
       documents are with the ADs or in various stages of WG Last Call.
       Several others are ready for Last Call. (10 min.)


1.2 Proposed WG Milestones [Tim Polk (NIST)]


       The working group milestones are out of date.  New milestones are
       needed; these milestones need to satisfy IESG direction for an orderly
       closeout of WG activities. (10 min.)


2. PKIX WG Specifications


    2.1  Subject Identification Method  [TBD]

       http//www.ietf.org/internet-drafts/draft-ietf-pkix-sim-01.txt

       The current SIM draft introduces a number of new parameters.
       While these parameters add additional complexity, they were
       required to satisfy the draft's security requirements.  The presentation
       will focus on the security requirements and proposed solution.
       Open issues will also be identified.  (10 min.)

    2.2 LDAP Schemas, String Values, and more
                                - David Chadwick (Univ of Salford)

       The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
       for LDAP based PKI information distribution.  New drafts will be 
published
       soon after this meeting; the presenter will discuss changes that will
       appear in the new drafts.  (15 min.)


    2.3 Qualified Certificates             Stefan Santesson

       http//www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-02.txt

       Work on the QC document has continued in both PKIX and ETSI.
       At least one more draft is envisioned; this presentation will decsribe
       planned updates and propose a path for completion of the QC document.
       (10 min.)

    2.4 Certification Path Building        Peter Hesse (Orion Security)

       http//www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-01.txt

       This document was written to provide guidance and
       recommendations to developers building X.509 public-key certification
       paths within their applications.  The next draft is aimed for WG Last
       Call; the presenter will discuss changes since -00 and additional
       changes projected for the forthcoming -02 draft. (10 min.)

    2.5  Certstore HTTP                    Peter Gutmann

       http//www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-05.txt 


       This draft proposes new procedures for certificate retrieval from
       an HTTP based repository.  Progression of this document would
       result in conflicting PKI protocols for HTTP-based repositories,
       and has not been able to progress.  (5 min.)

    2.6  OCSP                               Mike Myers (FastQ)

       http//www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-05.txt 


       A number of issues regarding OCSP have resurfaced on the mailing
       list.  The presenter will summarize the issues from the mailing
       list and present a way forward.  (5 min.)

3. Liaison/Related Projects

    The following specifications will update the WG on related activities.


    3.1 OASIS PKI survey                        Steve Hanna (Sun)

       The OASIS Public Key Infrastructure Technical Committee
       conducted a web-based survey to identify the key barriers
       to PKI deployment and usage.  The TC is currently developing an Action
       to address these barriers.  The presentation will address the survey
       results and preview the action plan. (15 min.)

    3.2 Path Validation Protection Profiles     Tim Polk (NIST)

       NIST is currently performing the interoperability testing for RFC 3280.
       One aspect of that effort is the RFC 3280 path validation test suite
       developed jointly by NIST, DigitalNet, and NSA.  To promote independnet
       testing based on the test suite, NIST has submitted protection profiles
       for path validation modules for NIAP validation. (10 min.)





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFOakT094594 for <[e-mail]>; Fri, 31 Oct 2003 07:24:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VFOZti094593 for ietf-pkix-bks; Fri, 31 Oct 2003 07:24:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFOYkT094585 for <[e-mail]>; Fri, 31 Oct 2003 07:24:35 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t12o913p45.telia.com [213.64.28.165]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id h9VFOUnw013874 for <[e-mail]>; Fri, 31 Oct 2003 16:24:31 +0100 (CET)
Message-ID: <00e101c39fc2$a59fa200$3a1b40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Web-PKI Keygen/Certreq Questions
Date: Fri, 31 Oct 2003 16:21:23 +0100
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 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear List,

After verifying that Web-signing is indeed both a much wanted
thing, as well as being in a miserable state standards-wise, I took
the liberty to check out another piece in the Web-PKI puzzle:

I cannot find any "compilation" of browser (on-line)-adapted mechanisms
for performing key generation or performing certificate requests.
This may be due to a limited effort on my part, but I suspect this
is just another "black hole" with respect to interoperability. 
Please tell me I'm wrong!

Looking at Microsoft's CertSrv for W2K, I found that IE and
Navigator are supplied with very different code.  IE seems to
only rely on MSFT's proprietary "Xenroll" stuff, while Navigator
uses a Netscape proprietary HTML tag called "KeyGen".

Any comments or information on this subject?

Sincerely
Anders Rundgren
Consultant, PKI & e-business

PS This is indeed off-topic for PKIX but not for the "PKI community"
     which to some extent is represented in PKIX  DS



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V2aJkT098953 for <[e-mail]>; Thu, 30 Oct 2003 18:36:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9V2aJAt098952 for ietf-pkix-bks; Thu, 30 Oct 2003 18:36:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V2aHkU098947 for <[e-mail]>; Thu, 30 Oct 2003 18:36:18 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0600206ebbc779d9d3fe@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <007501c39f00$60446fa0$[e-mail]> <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Thu, 30 Oct 2003 18:36:40 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Request change in son-of-rfc2633
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:02 PM -0500 10/30/03, jim wrote:
>After the KEYJACKING paper that was presented at the last PKI 
>Development Conference, I am not clear on the push for using SMIME 
>since we know that any transactions using SSL or VPN technologies 
>subject the key to being compromised.

The paper talks about scenarios that compromise the entire PC, not 
just S/MIME. So you are saying "if the user can use client-side 
certs, you cannot trust anything on the PC ever again". That may be 
true, but it is irrelevant to the discussion of S/MIME and probably 
to PKIX as well.

PCs are vulnerable. This doesn't mean we stop all development of 
things that run on PCs.

(FWIW, the paper can be found at 
<http://www.cs.dartmouth.edu/~sws/papers/keyjack.pdf>.)

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V11rkT094977 for <[e-mail]>; Thu, 30 Oct 2003 17:01:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9V11rXr094976 for ietf-pkix-bks; Thu, 30 Oct 2003 17:01:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.mivlmd.cablespeed.com (smtp2.mivlmd.cablespeed.com [24.35.0.19]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9V11qkT094970 for <[e-mail]>; Thu, 30 Oct 2003 17:01:52 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 31333 invoked by uid 0); 31 Oct 2003 01:00:54 -0000
Received: from unknown (HELO cablespeed.com) (24.35.57.71) by 0 with SMTP; 31 Oct 2003 01:00:54 -0000
Message-ID: <[e-mail]>
Date: Thu, 30 Oct 2003 20:02:32 -0500
From: jim <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Request change in son-of-rfc2633
References: <007501c39f00$60446fa0$[e-mail]>
Content-Type: multipart/alternative; boundary="------------040505080708010004040903"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------040505080708010004040903
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

After the KEYJACKING paper that was presented at the last PKI 
Development Conference, I am not clear on the push for using SMIME since 
we know that any transactions using SSL or VPN technologies subject the 
key to being compromised.  Is there some new technology that I am not 
familiar with and has that been reviewed by the team from Dartmouth that 
presented the paper to see if it was truly better?

Jim Heimberg, ABC, Ph.D.


Santosh Chokhani wrote:

>Tom:
>
>If the new Sub CA is rogue, name chaining will not help.  The CA who now
>uses the compromise key can always issue certificates to those RP and assert
>its own name.
>
>If the new sub CA is not rogue and someone else compromised the original sub
>CA key, that "someone else" can use the compromised key under the new CA
>name to create bogus RPs.
>
>If everything is benign, the original CA was revoked and not compromised,
>some one could provide a certification path: root .....--> new CA --> RP
>under old CA.  Without name chaining, this path could be validated and thus,
>if the RP was compromised, that compromise can be exploited.  But, this is
>only if the two CAs benignly use the same key. 
>
>-----Original Message-----
>From: Tom Biskupic [mailto:[e-mail]] 
>Sent: Thursday, October 30, 2003 1:29 AM
>To: 'Santosh Chokhani'; [e-mail]
>Subject: RE: Request change in son-of-rfc2633
>
>
>Hello,
>
>Umm What about if you managed to have a Sub-CA certified using the
>compromised key of another Sub CA?
>
>The other sub CA was revoked (for key compromise) and therefore all the
>certificates it issued are dead but if RP applications ignore the
>name-chaining, wouldn't this effectively re-activate those certificates? RPs
>checking one of those dead certs (and ignoring name chaining) could use the
>newly certified Sub CA to build a (well bogus) path and would accept that
>path.
>
>Even POP won't save you as the entity applying to have the compromised CA
>key re-certified may have the private key (as it was compromised).
>
>Some CAs will check that the same key is not issued to two entities (and
>thus would refuse to re-certify the Sub CA with a different name) however do
>you want to rely on it?
>
>Ok this is a bit theoretical... A Sub-CA being revoked for instance.
>
>Tom
>
>  
>
>>-----Original Message-----
>>From: Santosh Chokhani [mailto:[e-mail]]
>>Sent: Thursday, 30 October 2003 07:51
>>To: [e-mail]; [e-mail]
>>Subject: RE: Request change in son-of-rfc2633
>>
>>
>>Steve Hanna:
>>
>>I agree with you that both 3280 and X.509 require name chaining. 
>>However, the security implications and security importance of name 
>>chaining is overstated.
>>
>>For example, if signatures chain properly for the certificate and CRL 
>>and the relying party has appropriate means (e.g., e-mail
>>address) to identify
>>the subscriber, name chaining offers little in terms of security.
>>
>>My statement should be read purely in security (and NOT
>>interoperability)
>>context.
>>
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]]
>>On Behalf Of Steve Hanna
>>Sent: Wednesday, October 29, 2003 9:58 AM
>>To: Peter Gutmann
>>Cc: [e-mail]; [e-mail]; [e-mail]
>>Subject: Re: Request change in son-of-rfc2633
>>
>>
>>Anyone who "reads the PKIX tea leaves" and thinks that
>>it's fine to skip name chaining checks in path validation needs to
>>have their eyes checked. RFC 3280 says in many places that name 
>>chaining MUST be checked.
>>
>>In section 6.1:
>>
>> To meet this goal, the path validation process verifies, among other
>>things, that a prospective certification path (a sequence of n
>> certificates) satisfies the following conditions:
>>
>>    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
>>    the issuer of certificate x+1;
>>
>>In section 6.1.3:
>>
>> (a)  Verify the basic certificate information.  The certificate  MUST
>>satisfy each of the following:
>>
>> [...]
>>
>>    (4)  The certificate issuer name is the working_issuer_name.
>>
>>In section 4.1.2.6:
>>
>>   If the subject is a CA (e.g., the basic constraints extension, as
>>   discussed in 4.2.1.10, is present and the value of cA is TRUE), 
>>then
>>   the subject field MUST be populated with a non-empty distinguished
>>   name matching the contents of the issuer field (section 4.1.2.4) in
>>   all certificates issued by the subject CA.
>>
>>RFC 2459 and X.509 both agree with this.
>>
>>Whatever PKI topology you use, there's no need to break
>>name chaining. I'm sure that some customers have created
>>PKIs where name chaining doesn't hold, but that's an error
>>on the customer's part. You can't just turn off critical security 
>>checks to keep them happy. What's next? Don't bother checking the 
>>signature on certificates. That takes too much time!
>>
>>If somebody has implemented path validation without name chaining 
>>checks, then they haven't implemented it according to IETF or X.509 
>>standards. In fact, they may have opened themselves and their 
>>customers up to security
>>holes and perhaps even legal liability. CAs have every right to expect
>>that certificates will be validated according to standards. Users also
>>have a reasonable expectation of this. If someone 
>>deliberately violates
>>the standards in a way that opens up security holes, that sounds like
>>gross negligence to me.
>>
>>This reminds me of Microsoft's decision to not check the Basic
>>Constraints extension, treating every certificate as a CA certificate. 
>>This decision, presumably made in to please a customer, resulted in a 
>>HUGE security hole.
>>
>>I hope that Microsoft (and anyone else who has skipped required parts
>>of the path validation algorithm for the sake of convenience) will see 
>>that security cannot be second to user convenience. If there's a 
>>serious problem with the specs, then let's fix them. But don't just 
>>bypass things because you find it convenient.
>>
>>Forgive me my rant. I'm just outraged that somebody would play fast
>>and loose with security this way.
>>
>>Thanks,
>>
>>Steve
>>
>>Peter Gutmann wrote:
>>    
>>
>>>[Cross-posted back to S/MIME, where the thread started]
>>>
>>>Eric Norman <[e-mail]> writes:
>>>
>>>      
>>>
>>>>Is there a claim (#1 above) that you can have the DN in the subject
>>>>of a parent's (signer's) certificate be different from (as in 
>>>>different bunch of
>>>>bytes) the DN in the issuer of one of its offspring and
>>>>        
>>>>
>>yet the chain
>>is
>>    
>>
>>>>still valid because the xKIDs match?
>>>>        
>>>>
>>>Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI
>>>that violates the original X.509 design, i.e. with re-parenting, 
>>>arbitrary cross- certification, etc etc where issuers no
>>>      
>>>
>>longer match
>>    
>>
>>>subjects).  For example MS apparently implemented chaining
>>>      
>>>
>>by sKID in
>>    
>>
>>>Windows because of user demand for this when the users
>>>      
>>>
>>broke chaining
>>    
>>
>>>by issuer name through spaghetti PKI design practices, and various
>>>other implementations no doubt do similar things, depending on how 
>>>they've read the PKIX tea leaves.
>>>
>>>Peter.
>>>      
>>>
>
>
>
>
>  
>


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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
After the KEYJACKING paper that was presented at the last PKI Development
Conference, I am not clear on the push for using SMIME since we know that
any transactions using SSL or VPN technologies subject the key to being compromised.
&nbsp;Is there some new technology that I am not familiar with and has that been
reviewed by the team from Dartmouth that presented the paper to see if it
was truly better?<br>
<br>
Jim Heimberg, ABC, Ph.D.<br>
<br>
<br>
Santosh Chokhani wrote:<br>
<blockquote type="cite"
 cite="mid007501c39f00$60446fa0$[e-mail]">
  <pre wrap="">Tom:

If the new Sub CA is rogue, name chaining will not help.  The CA who now
uses the compromise key can always issue certificates to those RP and assert
its own name.

If the new sub CA is not rogue and someone else compromised the original sub
CA key, that "someone else" can use the compromised key under the new CA
name to create bogus RPs.

If everything is benign, the original CA was revoked and not compromised,
some one could provide a certification path: root .....--&gt; new CA --&gt; RP
under old CA.  Without name chaining, this path could be validated and thus,
if the RP was compromised, that compromise can be exploited.  But, this is
only if the two CAs benignly use the same key. 

-----Original Message-----
From: Tom Biskupic [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>] 
Sent: Thursday, October 30, 2003 1:29 AM
To: 'Santosh Chokhani'; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Subject: RE: Request change in son-of-rfc2633


Hello,

Umm What about if you managed to have a Sub-CA certified using the
compromised key of another Sub CA?

The other sub CA was revoked (for key compromise) and therefore all the
certificates it issued are dead but if RP applications ignore the
name-chaining, wouldn't this effectively re-activate those certificates? RPs
checking one of those dead certs (and ignoring name chaining) could use the
newly certified Sub CA to build a (well bogus) path and would accept that
path.

Even POP won't save you as the entity applying to have the compromised CA
key re-certified may have the private key (as it was compromised).

Some CAs will check that the same key is not issued to two entities (and
thus would refuse to re-certify the Sub CA with a different name) however do
you want to rely on it?

Ok this is a bit theoretical... A Sub-CA being revoked for instance.

Tom

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: Santosh Chokhani [<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
Sent: Thursday, 30 October 2003 07:51
To: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Subject: RE: Request change in son-of-rfc2633


Steve Hanna:

I agree with you that both 3280 and X.509 require name chaining. 
However, the security implications and security importance of name 
chaining is overstated.

For example, if signatures chain properly for the certificate and CRL 
and the relying party has appropriate means (e.g., e-mail
address) to identify
the subscriber, name chaining offers little in terms of security.

My statement should be read purely in security (and NOT
interoperability)
context.

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> 
[<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]
On Behalf Of Steve Hanna
Sent: Wednesday, October 29, 2003 9:58 AM
To: Peter Gutmann
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Subject: Re: Request change in son-of-rfc2633


Anyone who "reads the PKIX tea leaves" and thinks that
it's fine to skip name chaining checks in path validation needs to
have their eyes checked. RFC 3280 says in many places that name 
chaining MUST be checked.

In section 6.1:

 To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n
 certificates) satisfies the following conditions:

    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
    the issuer of certificate x+1;

In section 6.1.3:

 (a)  Verify the basic certificate information.  The certificate  MUST
satisfy each of the following:

 [...]

    (4)  The certificate issuer name is the working_issuer_name.

In section 4.1.2.6:

   If the subject is a CA (e.g., the basic constraints extension, as
   discussed in 4.2.1.10, is present and the value of cA is TRUE), 
then
   the subject field MUST be populated with a non-empty distinguished
   name matching the contents of the issuer field (section 4.1.2.4) in
   all certificates issued by the subject CA.

RFC 2459 and X.509 both agree with this.

Whatever PKI topology you use, there's no need to break
name chaining. I'm sure that some customers have created
PKIs where name chaining doesn't hold, but that's an error
on the customer's part. You can't just turn off critical security 
checks to keep them happy. What's next? Don't bother checking the 
signature on certificates. That takes too much time!

If somebody has implemented path validation without name chaining 
checks, then they haven't implemented it according to IETF or X.509 
standards. In fact, they may have opened themselves and their 
customers up to security
holes and perhaps even legal liability. CAs have every right to expect
that certificates will be validated according to standards. Users also
have a reasonable expectation of this. If someone 
deliberately violates
the standards in a way that opens up security holes, that sounds like
gross negligence to me.

This reminds me of Microsoft's decision to not check the Basic
Constraints extension, treating every certificate as a CA certificate. 
This decision, presumably made in to please a customer, resulted in a 
HUGE security hole.

I hope that Microsoft (and anyone else who has skipped required parts
of the path validation algorithm for the sake of convenience) will see 
that security cannot be second to user convenience. If there's a 
serious problem with the specs, then let's fix them. But don't just 
bypass things because you find it convenient.

Forgive me my rant. I'm just outraged that somebody would play fast
and loose with security this way.

Thanks,

Steve

Peter Gutmann wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">[Cross-posted back to S/MIME, where the thread started]

Eric Norman <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a> writes:

      </pre>
      <blockquote type="cite">
        <pre wrap="">Is there a claim (#1 above) that you can have the DN in the subject
of a parent's (signer's) certificate be different from (as in 
different bunch of
bytes) the DN in the issuer of one of its offspring and
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">yet the chain
is
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">still valid because the xKIDs match?
        </pre>
      </blockquote>
      <pre wrap="">Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI
that violates the original X.509 design, i.e. with re-parenting, 
arbitrary cross- certification, etc etc where issuers no
      </pre>
    </blockquote>
    <pre wrap="">longer match
    </pre>
    <blockquote type="cite">
      <pre wrap="">subjects).  For example MS apparently implemented chaining
      </pre>
    </blockquote>
    <pre wrap="">by sKID in
    </pre>
    <blockquote type="cite">
      <pre wrap="">Windows because of user demand for this when the users
      </pre>
    </blockquote>
    <pre wrap="">broke chaining
    </pre>
    <blockquote type="cite">
      <pre wrap="">by issuer name through spaghetti PKI design practices, and various
other implementations no doubt do similar things, depending on how 
they've read the PKIX tea leaves.

Peter.
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->



  </pre>
</blockquote>
<br>
</body>
</html>

--------------040505080708010004040903--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V050kT092454 for <[e-mail]>; Thu, 30 Oct 2003 16:05:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9V05056092453 for ietf-pkix-bks; Thu, 30 Oct 2003 16:05:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9V04wkT092447 for <[e-mail]>; Thu, 30 Oct 2003 16:04:58 -0800 (PST) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9V04jn9632758; Thu, 30 Oct 2003 19:04:45 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9V04iYG077764; Thu, 30 Oct 2003 19:04:44 -0500
To: "Michael Myers" <[e-mail]>
Cc: "David Engberg" <[e-mail]>, [e-mail]
MIME-Version: 1.0
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 30 Oct 2003 19:04:12 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 PMR38084 MIAS5SCKSP SASF5LTQFD GCHU5LFQD5 JHEG5PKRJT MIAS5RMQQF ALEE5RFGW8+|October 16, 2003) at 10/30/2003 19:04:44, Serialize complete at 10/30/2003 19:04:44
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        I should have been more precise in my suggestion.  The unilateral 
server-specified practice I can think of that would most effectively ban 
relays is for an extension called nonceSupported to be defined, whose 
syntax is a single Boolean.  A responder supporting this extension should 
include it, with the appropriate value, in every response other than those 
which contain nonces.  This extension is of limited value in responses 
which do contain nonces, although you could put it in them.  With such an 
extension, any replay of a response from a responder with nonce support 
would be detectable by the client.  If the client doesn't use nonces, or 
the responder doesn't support them, I don't see what you can do to detect 
replays.
        It would be possible to make the value of such an extension a 
3-valued enumeration: unsupported, deprecated (meaning it's expensive but 
we'll do it if you insist), and supported.  That variant would probably be 
called "nonceSupport", and it might be desirable to include that in 
responses which include nonces as well as in those which don't.  However, 
we'd need yet another mechanism to demand a response including a nonce in 
order to support the deprecated value.
        I am not suggesting that anyone standardize both of these 
variants, which would be egregious bloat.  I won't be at Minneapolis, so 
I'm getting my suggestions in early.

                Tom Gindin

        IMHO, a client should take the following action where the 
requestor includes a nonce:
a)      Nonce present, accept if response.nonce == request.nonce
b)      NonceSupported == false (with no nonce), accept (also NonceSupport 
== unsupported)
c)      NonceSupported == true but no nonce, reject             (also 
NonceSupport == supported)
d)      NonceUnsupported present (with no nonce), accept
e)      Neither nonce nor extension present, DEBATABLE (see this thread 
for the debate)
f)      NonceSupport == deprecated (with no nonce), accept or rerequest 
(BUT there's no good rerequest technique)






"Michael Myers" <[e-mail]>
10/22/2003 12:49 PM

 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     "David Engberg" <[e-mail]>, <[e-mail]>
        Subject:        RE: DISCUSSION: Nonce-specific error code for OCSP



Tom,

Your proposal certainly provides an opportunity for compromise.
But I think we first need to see what emerges from Minneapolis.

Mike

> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Wednesday, October 22, 2003 9:19 AM
> To: Michael Myers
> Cc: David Engberg; [e-mail]
> Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
>
>
>         Michael:
>
>         Does your skepticism about the usefulness of
> unilateral
> server-side extensions mean that we should permit a
> variant of nonce in
> which the client specifies how strongly he needs a
> nonce?  Since the
> current syntax of nonce is not officially published,
> I posted a possible
> extension several weeks ago.  The options were
> original (with unclear
> semantics in this respect), nonce required in
> response, and nonce optional
> in response.
>         For a server to actually prevent
> misunderstandings of whether or
> not he supports nonces by using a unilateral
> server-side extension, you'd
> need a server-side extension called "nonceSupported"
> with boolean syntax,
> which would have to be placed in EVERY response
> whether nonces are present
> in the request or not.  The "nonceUnsupported"
> extension strikes me as
> less useful than that.
>
>                 Tom Gindin
>







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGiYkT071752 for <[e-mail]>; Thu, 30 Oct 2003 08:44:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UGiYOg071751 for ietf-pkix-bks; Thu, 30 Oct 2003 08:44:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.fre.skanova.net (smtp2.fre.skanova.net [195.67.227.95]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGiUkT071728 for <[e-mail]>; Thu, 30 Oct 2003 08:44:31 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t12o913p71.telia.com [213.64.28.191]) by smtp2.fre.skanova.net (8.12.10/8.12.10) with SMTP id h9UGi9Ed024555; Thu, 30 Oct 2003 17:44:10 +0100 (CET)
Message-ID: <006401c39f04$a0cde700$bf1c40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Karl Scheibelhofer" <[e-mail]>, "Florian Oelmaier" <[e-mail]>, <[e-mail]>
Cc: "'James Jing'" <[e-mail]>, "'Markus Lorch'" <[e-mail]>
References: <000101c39e38$ee9e6120$4228a8c0@hagen> <011001c39eec$96588540$d21a40d5@arport> <00d401c39f00$e1c275e0$[e-mail]>
Subject: Re: Standards for Web-signing II
Date: Thu, 30 Oct 2003 17:41:04 +0100
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Karl,

Thanx for the pointer!
However, although DSS indeed talks about the Web, Interfaces
and Signatures, this is AFAIU an entirely "programmatic"
web where things like WYSIWYS is of no importance.

To really screw up things, you need users and that calls for
something else.  Like a new standard :-)

Best
Anders

----- Original Message ----- 
From: "Karl Scheibelhofer" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; "Florian Oelmaier" <[e-mail]>; <[e-mail]>
Cc: "'James Jing'" <[e-mail]>; "'Markus Lorch'" <[e-mail]>
Sent: Thursday, October 30, 2003 17:14
Subject: Re: Standards for Web-signing II


as far as i know OASIS has started related efforts. see
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss

  Karl

--

Karl Scheibelhofer, IAIK - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Fax: [phone]
http://jce.iaik.tugraz.at


----- Original Message ----- 
From: "Anders Rundgren" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>; <[e-mail]>
Cc: "'James Jing'" <[e-mail]>; "'Markus Lorch'"
<[e-mail]>
Sent: Thursday, October 30, 2003 2:49 PM
Subject: Re: Standards for Web-signing II


>
> Apologizes Steven.   Last comment.  This one is actually a bit
> interesting for any die-hard cryptographer.
>
> Thanx Florian,
>
> The manual to "Personal" is thick but leaves out all "hardcore" stuff
like:
>
> If MIME is "text/html" does it calculate hash of embedded objects?
> Actually what algorithm does it use for cononicalization of HTML or
> even for TXT?
>
> And what happens if you use "PKCS7SIGNED_Attached" and
> have MIME "text/html" and use embedded objects (IMGs)?  I don't
> think I want to know!  It will probably explode and crash my hard-disk :-)
> Or does it falsely just include the HTML disregarding WYSIWYS
> completely?
>
> My firm belief is that on-line signatures is a very different "animal"
> compared to signed e-mails, and MUST be designed from the ground
> and up in order to EVER work in an interoperable and useful manner.
>
> So where do we go now?  To CEN/ISSS, W3C, OASIS, IETF or what?
>
> Regards
> Anders Rundgren
>
> ----- Original Message -----
> From: "Florian Oelmaier" <[e-mail]>
> To: "'Anders Rundgren'" <[e-mail]>; "'James Jing'"
<[e-mail]>; "'Markus Lorch'" <[e-mail]>;
> <[e-mail]>
> Sent: Wednesday, October 29, 2003 17:23
> Subject: RE: Standards for Web-signing II
>
>
> > However, Identrus is a bank-controlled operation and
> > therefore operate in the same way as banks regarding their
> > technology. I.e. by acting "possessive" and most of all being
> > scared that a competitor would ever be able to profit on the
> > work done.
>
> We all know that acting "possessive" does not work really good on the
> internet. After all a secrect shared by more than three people isnt a
> secret anymore. If you need a hint at how the identrus Websigning works
> you may look at
> http://www.s-d.no/filer/manualer/Technical%20Description%203_1Rev1.pdf
> and read the identrus section there.
>
> --
> Florian Oelmaier
> SyTrust
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGR6kT070792 for <[e-mail]>; Thu, 30 Oct 2003 08:27:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UGR6q8070791 for ietf-pkix-bks; Thu, 30 Oct 2003 08:27:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mclean-vscan3.bah.com (mclean-vscan3.bah.com [156.80.3.63]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGR5kT070773 for <[e-mail]>; Thu, 30 Oct 2003 08:27:05 -0800 (PST) (envelope-from [e-mail])
Received: from mclean-vscan3.bah.com (mclean-vscan3.bah.com [156.80.3.63]) by mclean-vscan3.bah.com (8.11.0/8.11.0) with SMTP id h9UGQkA29570 for <[e-mail]>; Thu, 30 Oct 2003 11:26:46 -0500 (EST)
Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan3.bah.com (NAVGW 2.5.2.12) with SMTP id M2003103011110229012 for <[e-mail]>; Thu, 30 Oct 2003 11:11:02 -0500
Received: from wchokhani ([156.80.127.102]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HNKVMC00.F7A for <[e-mail]>; Thu, 30 Oct 2003 11:11:00 -0500 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Request change in son-of-rfc2633
Date: Thu, 30 Oct 2003 11:10:57 -0500
Message-ID: <007901c39f00$67ee9050$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9UGR5kT070786
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Walt:

My comment was purely for checking the names during path validation.  I did
not say that you do not assert the names and do not make these available to
the RP as part of certification path.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, October 30, 2003 9:19 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Request change in son-of-rfc2633



> I agree with you that both 3280 and X.509 require name chaining.
However,
> the security implications and security importance of name chaining is 
> overstated.
>
> For example, if signatures chain properly for the certificate and CRL 
> and the relying party has appropriate means (e.g., e-mail address) to
identify
> the subscriber, name chaining offers little in terms of security.
>
> My statement should be read purely in security (and NOT 
> interoperability) context.

I think this isn't quite right, if you intended it the way I'm interpreting
what you've written.

You seem to be saying only that "the relying-party must have appropriate
means to identify the *leaf* subscriber".  But surely, the RP must also have
appropriate means to identify the intermediate CAs as well, else the RP
cannot evaluate the degree of trust it places in the cert-chain.  And, for
better or worse, the standard means of identifying CAs is DN (not, e.g.,
email addr).

As with your note, this comment is security-relevant, not an observation on
interoperability.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGI7kT070296 for <[e-mail]>; Thu, 30 Oct 2003 08:18:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UGI7p7070295 for ietf-pkix-bks; Thu, 30 Oct 2003 08:18:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGI6kT070289 for <[e-mail]>; Thu, 30 Oct 2003 08:18:06 -0800 (PST) (envelope-from [e-mail])
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by mclean-vscan1.bah.com (8.11.0/8.11.0) with SMTP id h9UGHte15544 for <[e-mail]>; Thu, 30 Oct 2003 11:17:55 -0500 (EST)
Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan1.bah.com (NAVGW 2.5.2.12) with SMTP id M2003103011104702142 for <[e-mail]>; Thu, 30 Oct 2003 11:10:47 -0500
Received: from wchokhani ([156.80.127.102]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HNKVLZ00.H63 for <[e-mail]>; Thu, 30 Oct 2003 11:10:47 -0500 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Request change in son-of-rfc2633
Date: Thu, 30 Oct 2003 11:10:12 -0500
Message-ID: <007501c39f00$60446fa0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; smime-type=signed-data; name="smime.p7m"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9UGI7kT070291
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom:

If the new Sub CA is rogue, name chaining will not help.  The CA who now
uses the compromise key can always issue certificates to those RP and assert
its own name.

If the new sub CA is not rogue and someone else compromised the original sub
CA key, that "someone else" can use the compromised key under the new CA
name to create bogus RPs.

If everything is benign, the original CA was revoked and not compromised,
some one could provide a certification path: root .....--> new CA --> RP
under old CA.  Without name chaining, this path could be validated and thus,
if the RP was compromised, that compromise can be exploited.  But, this is
only if the two CAs benignly use the same key. 

-----Original Message-----
From: Tom Biskupic [mailto:[e-mail]] 
Sent: Thursday, October 30, 2003 1:29 AM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: Request change in son-of-rfc2633


Hello,

Umm What about if you managed to have a Sub-CA certified using the
compromised key of another Sub CA?

The other sub CA was revoked (for key compromise) and therefore all the
certificates it issued are dead but if RP applications ignore the
name-chaining, wouldn't this effectively re-activate those certificates? RPs
checking one of those dead certs (and ignoring name chaining) could use the
newly certified Sub CA to build a (well bogus) path and would accept that
path.

Even POP won't save you as the entity applying to have the compromised CA
key re-certified may have the private key (as it was compromised).

Some CAs will check that the same key is not issued to two entities (and
thus would refuse to re-certify the Sub CA with a different name) however do
you want to rely on it?

Ok this is a bit theoretical... A Sub-CA being revoked for instance.

Tom

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, 30 October 2003 07:51
> To: [e-mail]; [e-mail]
> Subject: RE: Request change in son-of-rfc2633
> 
> 
> Steve Hanna:
> 
> I agree with you that both 3280 and X.509 require name chaining. 
> However, the security implications and security importance of name 
> chaining is overstated.
> 
> For example, if signatures chain properly for the certificate and CRL 
> and the relying party has appropriate means (e.g., e-mail
> address) to identify
> the subscriber, name chaining offers little in terms of security.
> 
> My statement should be read purely in security (and NOT
> interoperability)
> context.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of Steve Hanna
> Sent: Wednesday, October 29, 2003 9:58 AM
> To: Peter Gutmann
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Request change in son-of-rfc2633
> 
> 
> Anyone who "reads the PKIX tea leaves" and thinks that
> it's fine to skip name chaining checks in path validation needs to
> have their eyes checked. RFC 3280 says in many places that name 
> chaining MUST be checked.
> 
> In section 6.1:
> 
>  To meet this goal, the path validation process verifies, among other
> things, that a prospective certification path (a sequence of n
>  certificates) satisfies the following conditions:
> 
>     (a)  for all x in {1, ..., n-1}, the subject of certificate x is
>     the issuer of certificate x+1;
> 
> In section 6.1.3:
> 
>  (a)  Verify the basic certificate information.  The certificate  MUST
> satisfy each of the following:
> 
>  [...]
> 
>     (4)  The certificate issuer name is the working_issuer_name.
> 
> In section 4.1.2.6:
> 
>    If the subject is a CA (e.g., the basic constraints extension, as
>    discussed in 4.2.1.10, is present and the value of cA is TRUE), 
> then
>    the subject field MUST be populated with a non-empty distinguished
>    name matching the contents of the issuer field (section 4.1.2.4) in
>    all certificates issued by the subject CA.
> 
> RFC 2459 and X.509 both agree with this.
> 
> Whatever PKI topology you use, there's no need to break
> name chaining. I'm sure that some customers have created
> PKIs where name chaining doesn't hold, but that's an error
> on the customer's part. You can't just turn off critical security 
> checks to keep them happy. What's next? Don't bother checking the 
> signature on certificates. That takes too much time!
> 
> If somebody has implemented path validation without name chaining 
> checks, then they haven't implemented it according to IETF or X.509 
> standards. In fact, they may have opened themselves and their 
> customers up to security
> holes and perhaps even legal liability. CAs have every right to expect
> that certificates will be validated according to standards. Users also
> have a reasonable expectation of this. If someone 
> deliberately violates
> the standards in a way that opens up security holes, that sounds like
> gross negligence to me.
> 
> This reminds me of Microsoft's decision to not check the Basic
> Constraints extension, treating every certificate as a CA certificate. 
> This decision, presumably made in to please a customer, resulted in a 
> HUGE security hole.
> 
> I hope that Microsoft (and anyone else who has skipped required parts
> of the path validation algorithm for the sake of convenience) will see 
> that security cannot be second to user convenience. If there's a 
> serious problem with the specs, then let's fix them. But don't just 
> bypass things because you find it convenient.
> 
> Forgive me my rant. I'm just outraged that somebody would play fast
> and loose with security this way.
> 
> Thanks,
> 
> Steve
> 
> Peter Gutmann wrote:
> >
> > [Cross-posted back to S/MIME, where the thread started]
> >
> > Eric Norman <[e-mail]> writes:
> >
> > >Is there a claim (#1 above) that you can have the DN in the subject
> > >of a parent's (signer's) certificate be different from (as in 
> > >different bunch of
> > >bytes) the DN in the issuer of one of its offspring and
> yet the chain
> is
> > >still valid because the xKIDs match?
> >
> > Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI
> > that violates the original X.509 design, i.e. with re-parenting, 
> > arbitrary cross- certification, etc etc where issuers no
> longer match
> > subjects).  For example MS apparently implemented chaining
> by sKID in
> > Windows because of user demand for this when the users
> broke chaining
> > by issuer name through spaghetti PKI design practices, and various
> > other implementations no doubt do similar things, depending on how 
> > they've read the PKIX tea leaves.
> >
> > Peter.
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UEJPkT063486 for <[e-mail]>; Thu, 30 Oct 2003 06:19:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UEJPxj063485 for ietf-pkix-bks; Thu, 30 Oct 2003 06:19:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from c2.groove.net (groove.net [63.209.254.203] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UEJOkT063473 for <[e-mail]>; Thu, 30 Oct 2003 06:19:24 -0800 (PST) (envelope-from [e-mail])
Received: from notes.internalgroove.net (notes.internalgroove.net [10.11.8.20]) by c2.groove.net (8.9.3/8.9.3) with SMTP id OAA06718; Thu, 30 Oct 2003 14:18:39 GMT
From: [e-mail]
Subject: RE: Request change in son-of-rfc2633
To: "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
Date: Thu, 30 Oct 2003 09:18:41 -0500
X-MIMETrack: Serialize by Router on Rich/Groove(Release 5.0.12  |February 13, 2003) at 10/30/2003 09:18:48 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I agree with you that both 3280 and X.509 require name chaining.
However,
> the security implications and security importance of name chaining is
> overstated.
>
> For example, if signatures chain properly for the certificate and CRL and
> the relying party has appropriate means (e.g., e-mail address) to
identify
> the subscriber, name chaining offers little in terms of security.
>
> My statement should be read purely in security (and NOT interoperability)
> context.

I think this isn't quite right, if you intended it the way I'm interpreting
what you've written.

You seem to be saying only that "the relying-party must have appropriate
means to identify the *leaf* subscriber".  But surely, the RP must also
have appropriate means to identify the intermediate CAs as well, else the
RP cannot evaluate the degree of trust it places in the cert-chain.  And,
for better or worse, the standard means of identifying CAs is DN (not,
e.g., email addr).

As with your note, this comment is security-relevant, not an observation on
interoperability.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UDqEkT061374 for <[e-mail]>; Thu, 30 Oct 2003 05:52:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UDqEPX061373 for ietf-pkix-bks; Thu, 30 Oct 2003 05:52:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UDqCkT061366 for <[e-mail]>; Thu, 30 Oct 2003 05:52:13 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t7o913p91.telia.com [213.64.26.91]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id h9UDq8ta008654; Thu, 30 Oct 2003 14:52:09 +0100 (CET)
Message-ID: <011001c39eec$96588540$d21a40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, <[e-mail]>
Cc: "'James Jing'" <[e-mail]>, "'Markus Lorch'" <[e-mail]>
References: <000101c39e38$ee9e6120$4228a8c0@hagen>
Subject: Re: Standards for Web-signing II
Date: Thu, 30 Oct 2003 14:49:03 +0100
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Apologizes Steven.   Last comment.  This one is actually a bit
interesting for any die-hard cryptographer.

Thanx Florian,

The manual to "Personal" is thick but leaves out all "hardcore" stuff like:

If MIME is "text/html" does it calculate hash of embedded objects?
Actually what algorithm does it use for cononicalization of HTML or
even for TXT?

And what happens if you use "PKCS7SIGNED_Attached" and
have MIME "text/html" and use embedded objects (IMGs)?  I don't
think I want to know!  It will probably explode and crash my hard-disk :-)
Or does it falsely just include the HTML disregarding WYSIWYS
completely?

My firm belief is that on-line signatures is a very different "animal"
compared to signed e-mails, and MUST be designed from the ground
and up in order to EVER work in an interoperable and useful manner.

So where do we go now?  To CEN/ISSS, W3C, OASIS, IETF or what?

Regards
Anders Rundgren

----- Original Message -----
From: "Florian Oelmaier" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>; "'James Jing'" <[e-mail]>; "'Markus Lorch'" <[e-mail]>;
<[e-mail]>
Sent: Wednesday, October 29, 2003 17:23
Subject: RE: Standards for Web-signing II


> However, Identrus is a bank-controlled operation and
> therefore operate in the same way as banks regarding their
> technology. I.e. by acting "possessive" and most of all being
> scared that a competitor would ever be able to profit on the
> work done.

We all know that acting "possessive" does not work really good on the
internet. After all a secrect shared by more than three people isnt a
secret anymore. If you need a hint at how the identrus Websigning works
you may look at
http://www.s-d.no/filer/manualer/Technical%20Description%203_1Rev1.pdf
and read the identrus section there.

--
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UC5ekT055894 for <[e-mail]>; Thu, 30 Oct 2003 04:05:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UC5epI055893 for ietf-pkix-bks; Thu, 30 Oct 2003 04:05:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UC5ckT055888 for <[e-mail]>; Thu, 30 Oct 2003 04:05:39 -0800 (PST) (envelope-from [e-mail])
Received: from Baltimore-FW2 ([172.19.1.2]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h9UBuoQ11724 for <[e-mail]>; Thu, 30 Oct 2003 11:56:50 GMT
Received: from  ([10.153.25.53]) by Baltimore-FW2; Thu, 30 Oct 2003 12:01:08 +0000 (GMT)
Received: from Baltimore-FW2 (wilde-i-2.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.10) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 30 Oct 2003 12:01:59 +0000
Received: from  ([10.153.25.10]) by Baltimore-FW2; Thu, 30 Oct 2003 12:01:06 +0000 (GMT)
Received: from emeairlbh1.ie.baltimore.com (emeairlbh1.ie.baltimore.com [10.153.25.54]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA23269; Thu, 30 Oct 2003 12:04:37 GMT
Received: by emeairlbh1.ie.baltimore.com with Internet Mail Service (5.5.2653.19) id <4SD7YW2J>; Thu, 30 Oct 2003 12:18:04 -0000
Message-ID: <[e-mail]>
From: Tom Biskupic <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: Request change in son-of-rfc2633
Date: Thu, 30 Oct 2003 11:56:28 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-OC-MailScanner: 
X-OC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.9, required 5, BAYES_00 -4.90)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Oops my appologies the previous version of this message went out signed with
a test certificate.

Here is the text again.

Tom

> -----Original Message-----
> From: Tom Biskupic [mailto:[e-mail]]
> Sent: Thursday, 30 October 2003 17:29
> To: 'Santosh Chokhani'; [e-mail]
> Subject: RE: Request change in son-of-rfc2633
> 
> 
> Hello,
> 
> Umm What about if you managed to have a Sub-CA certified using the
> compromised key of another Sub CA?
> 
> The other sub CA was revoked (for key compromise) and 
> therefore all the
> certificates it issued are dead but if RP applications ignore the
> name-chaining, wouldn't this effectively re-activate those 
> certificates?
> RPs checking one of those dead certs (and ignoring name 
> chaining) could
> use the newly certified Sub CA to build a (well bogus) path and would
> accept that path.
> 
> Even POP won't save you as the entity applying to have the compromised
> CA key re-certified may have the private key (as it was compromised).
> 
> Some CAs will check that the same key is not issued to two 
> entities (and
> thus would refuse to re-certify the Sub CA with a different name)
> however do you want to rely on it?
> 
> Ok this is a bit theoretical... A Sub-CA being revoked for instance.
> 
> Tom
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, 30 October 2003 07:51
> > To: [e-mail]; [e-mail]
> > Subject: RE: Request change in son-of-rfc2633
> > 
> > 
> > Steve Hanna:
> > 
> > I agree with you that both 3280 and X.509 require name 
> > chaining.  However,
> > the security implications and security importance of name 
> chaining is
> > overstated.
> > 
> > For example, if signatures chain properly for the certificate 
> > and CRL and
> > the relying party has appropriate means (e.g., e-mail 
> > address) to identify
> > the subscriber, name chaining offers little in terms of security.
> > 
> > My statement should be read purely in security (and NOT 
> > interoperability)
> > context.
> > 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]
> > On Behalf Of Steve Hanna
> > Sent: Wednesday, October 29, 2003 9:58 AM
> > To: Peter Gutmann
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > Subject: Re: Request change in son-of-rfc2633
> > 
> > 
> > Anyone who "reads the PKIX tea leaves" and thinks that
> > it's fine to skip name chaining checks in path validation
> > needs to have their eyes checked. RFC 3280 says in many
> > places that name chaining MUST be checked.
> > 
> > In section 6.1:
> > 
> >  To meet this goal, the path validation process verifies, 
> among other
> > things, that a prospective certification path (a sequence of n
> >  certificates) satisfies the following conditions:
> > 
> >     (a)  for all x in {1, ..., n-1}, the subject of certificate x is
> >     the issuer of certificate x+1;
> > 
> > In section 6.1.3:
> > 
> >  (a)  Verify the basic certificate information.  The 
> certificate  MUST
> > satisfy each of the following:
> > 
> >  [...]
> > 
> >     (4)  The certificate issuer name is the working_issuer_name.
> > 
> > In section 4.1.2.6:
> > 
> >    If the subject is a CA (e.g., the basic constraints extension, as
> >    discussed in 4.2.1.10, is present and the value of cA is 
> > TRUE), then
> >    the subject field MUST be populated with a non-empty 
> distinguished
> >    name matching the contents of the issuer field (section 
> 4.1.2.4) in
> >    all certificates issued by the subject CA.
> > 
> > RFC 2459 and X.509 both agree with this.
> > 
> > Whatever PKI topology you use, there's no need to break
> > name chaining. I'm sure that some customers have created
> > PKIs where name chaining doesn't hold, but that's an error
> > on the customer's part. You can't just turn off critical 
> > security checks
> > to keep them happy. What's next? Don't bother checking the 
> > signature on
> > certificates. That takes too much time!
> > 
> > If somebody has implemented path validation without name 
> > chaining checks,
> > then they haven't implemented it according to IETF or X.509 
> > standards. In
> > fact, they may have opened themselves and their customers up 
> > to security
> > holes and perhaps even legal liability. CAs have every 
> right to expect
> > that certificates will be validated according to standards. 
> Users also
> > have a reasonable expectation of this. If someone 
> > deliberately violates
> > the standards in a way that opens up security holes, that 
> sounds like
> > gross negligence to me.
> > 
> > This reminds me of Microsoft's decision to not check the
> > Basic Constraints extension, treating every certificate
> > as a CA certificate. This decision, presumably made in
> > to please a customer, resulted in a HUGE security hole.
> > 
> > I hope that Microsoft (and anyone else who has skipped
> > required parts of the path validation algorithm for the
> > sake of convenience) will see that security cannot be
> > second to user convenience. If there's a serious problem
> > with the specs, then let's fix them. But don't just bypass 
> > things because
> > you find it convenient.
> > 
> > Forgive me my rant. I'm just outraged that somebody would
> > play fast and loose with security this way.
> > 
> > Thanks,
> > 
> > Steve
> > 
> > Peter Gutmann wrote:
> > >
> > > [Cross-posted back to S/MIME, where the thread started]
> > >
> > > Eric Norman <[e-mail]> writes:
> > >
> > > >Is there a claim (#1 above) that you can have the DN in 
> the subject
> > > >of a parent's (signer's) certificate be different from (as in
> > > >different bunch of
> > > >bytes) the DN in the issuer of one of its offspring and 
> > yet the chain
> > is
> > > >still valid because the xKIDs match?
> > >
> > > Sure, in a spaghetti PKI (I'm using that as a generic 
> term for a PKI
> > > that violates the original X.509 design, i.e. with re-parenting,
> > > arbitrary cross- certification, etc etc where issuers no 
> > longer match
> > > subjects).  For example MS apparently implemented chaining 
> > by sKID in
> > > Windows because of user demand for this when the users 
> > broke chaining
> > > by issuer name through spaghetti PKI design practices, and various
> > > other implementations no doubt do similar things, depending on how
> > > they've read the PKIX tea leaves.
> > >
> > > Peter.
> > 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U6bdkT086068 for <[e-mail]>; Wed, 29 Oct 2003 22:37:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U6bcAH086067 for ietf-pkix-bks; Wed, 29 Oct 2003 22:37:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U6bbkT086017 for <[e-mail]>; Wed, 29 Oct 2003 22:37:37 -0800 (PST) (envelope-from [e-mail])
Received: from Baltimore-FW2 ([172.19.1.2]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h9U6TfQ09676 for <[e-mail]>; Thu, 30 Oct 2003 06:29:41 GMT
Received: from  ([10.153.25.53]) by Baltimore-FW2; Thu, 30 Oct 2003 06:33:58 +0000 (GMT)
Received: from Baltimore-FW2 (wilde-i-2.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.10) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 30 Oct 2003 06:34:49 +0000
Received: from  ([10.153.25.10]) by Baltimore-FW2; Thu, 30 Oct 2003 06:33:56 +0000 (GMT)
Received: from emeairlbh1.ie.baltimore.com (emeairlbh1.ie.baltimore.com [10.153.25.54]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id GAA19635; Thu, 30 Oct 2003 06:37:26 GMT
Received: by emeairlbh1.ie.baltimore.com with Internet Mail Service (5.5.2653.19) id <4SD7YVDC>; Thu, 30 Oct 2003 06:50:54 -0000
Message-ID: <[e-mail]>
From: Tom Biskupic <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: Request change in son-of-rfc2633
Date: Thu, 30 Oct 2003 06:29:18 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
X-OC-MailScanner: 
X-OC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.799, required 5, AWL 0.10, BAYES_00 -4.90)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEU0NvbnRl
bnQtVHlwZTogdGV4dC9wbGFpbjsNCgljaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNm
ZXItRW5jb2Rpbmc6IDdiaXQNCg0KBIIQAEhlbGxvLA0KDQpVbW0gV2hhdCBhYm91dCBpZiB5b3Ug
bWFuYWdlZCB0byBoYXZlIGEgU3ViLUNBIGNlcnRpZmllZCB1c2luZyB0aGUNCmNvbXByb21pc2Vk
IGtleSBvZiBhbm90aGVyIFN1YiBDQT8NCg0KVGhlIG90aGVyIHN1YiBDQSB3YXMgcmV2b2tlZCAo
Zm9yIGtleSBjb21wcm9taXNlKSBhbmQgdGhlcmVmb3JlIGFsbCB0aGUNCmNlcnRpZmljYXRlcyBp
dCBpc3N1ZWQgYXJlIGRlYWQgYnV0IGlmIFJQIGFwcGxpY2F0aW9ucyBpZ25vcmUgdGhlDQpuYW1l
LWNoYWluaW5nLCB3b3VsZG4ndCB0aGlzIGVmZmVjdGl2ZWx5IHJlLWFjdGl2YXRlIHRob3NlIGNl
cnRpZmljYXRlcz8NClJQcyBjaGVja2luZyBvbmUgb2YgdGhvc2UgZGVhZCBjZXJ0cyAoYW5kIGln
bm9yaW5nIG5hbWUgY2hhaW5pbmcpIGNvdWxkDQp1c2UgdGhlIG5ld2x5IGNlcnRpZmllZCBTdWIg
Q0EgdG8gYnVpbGQgYSAod2VsbCBib2d1cykgcGF0aCBhbmQgd291bGQNCmFjY2VwdCB0aGF0IHBh
dGguDQoNCkV2ZW4gUE9QIHdvbid0IHNhdmUgeW91IGFzIHRoZSBlbnRpdHkgYXBwbHlpbmcgdG8g
aGF2ZSB0aGUgY29tcHJvbWlzZWQNCkNBIGtleSByZS1jZXJ0aWZpZWQgbWF5IGhhdmUgdGhlIHBy
aXZhdGUga2V5IChhcyBpdCB3YXMgY29tcHJvbWlzZWQpLg0KDQpTb21lIENBcyB3aWxsIGNoZWNr
IHRoYXQgdGhlIHNhbWUga2V5IGlzIG5vdCBpc3N1ZWQgdG8gdHdvIGVudGl0aWVzIChhbmQNCnRo
dXMgd291bGQgcmVmdXNlIHRvIHJlLWNlcnRpZnkgdGhlIFN1YiBDQSB3aXRoIGEgZGlmZmVyZW50
IG5hbWUpDQpob3dldmVyIGRvIHlvdSB3YW50IHRvIHJlbHkgb24gaXQ/DQoNCk9rIHRoaXMgaXMg
YSBiaXQgdGhlb3JldGljYWwuLi4gQSBTdWItQ0EgYmVpbmcgcmV2b2tlZCBmb3IgaW5zdGFuY2Uu
DQoNClRvbQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNhbnRvc2gg
Q2hva2hhbmkgW21haWx0bzpjaG9raGFuaUBvcmlvbnNlYy5jb21dDQo+IFNlbnQ6IFRodXJzZGF5
LCAzMCBPY3RvYmVyIDIwMDMgMDc6NTENCj4gVG86IGlldGYtcGtpeEBpbWMub3JnOyBpZXRmLXNt
aW1lQGltYy5vcmcNCj4gU3ViamVjdDogUkU6IFJlcXVlc3QgY2hhbmdlIGluIHNvbi1vZi1yZmMy
NjMzDQo+IA0KPiANCj4gU3RldmUgSGFubmE6DQo+IA0KPiBJIGFncmVlIHdpdGggeW91IHRoYXQg
Ym90aCAzMjgwIGFuZCBYLjUwOSByZXF1aXJlIG5hbWUgDQo+IGNoYWluaW5nLiAgSG93ZXZlciwN
Cj4gdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBhbmQgc2VjdXJpdHkgaW1wb3J0YW5jZSBvZiBu
YW1lIGNoYWluaW5nIGlzDQo+IG92ZXJzdGF0ZWQuDQo+IA0KPiBGb3IgZXhhbXBsZSwgaWYgc2ln
bmF0dXJlcyBjaGFpbiBwcm9wZXJseSBmb3IgdGhlIGNlcnRpZmljYXRlIA0KPiBhbmQgQ1JMIGFu
ZA0KPiB0aGUgcmVseWluZyBwYXJ0eSBoYXMgYXBwcm9wcmlhdGUgbWVhbnMgKGUuZy4sIGUtbWFp
bCANCj4gYWRkcmVzcykgdG8gaWRlbnRpZnkNCj4gdGhlIHN1YnNjcmliZXIsIG5hbWUgY2hhaW5p
bmcgb2ZmZXJzIGxpdHRsZSBpbiB0ZXJtcyBvZiBzZWN1cml0eS4NCj4gDQo+IE15IHN0YXRlbWVu
dCBzaG91bGQgYmUgcmVhZCBwdXJlbHkgaW4gc2VjdXJpdHkgKGFuZCBOT1QgDQo+IGludGVyb3Bl
cmFiaWxpdHkpDQo+IGNvbnRleHQuDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiBGcm9tOiBvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnIA0KPiBbbWFpbHRvOm93bmVyLWll
dGYtcGtpeEBtYWlsLmltYy5vcmddDQo+IE9uIEJlaGFsZiBPZiBTdGV2ZSBIYW5uYQ0KPiBTZW50
OiBXZWRuZXNkYXksIE9jdG9iZXIgMjksIDIwMDMgOTo1OCBBTQ0KPiBUbzogUGV0ZXIgR3V0bWFu
bg0KPiBDYzogZWpub3JtYW5AZG9pdC53aXNjLmVkdTsgaWV0Zi1wa2l4QGltYy5vcmc7IGlldGYt
c21pbWVAaW1jLm9yZw0KPiBTdWJqZWN0OiBSZTogUmVxdWVzdCBjaGFuZ2UgaW4gc29uLW9mLXJm
YzI2MzMNCj4gDQo+IA0KPiBBbnlvbmUgd2hvICJyZWFkcyB0aGUgUEtJWCB0ZWEgbGVhdmVzIiBh
bmQgdGhpbmtzIHRoYXQNCj4gaXQncyBmaW5lIHRvIHNraXAgbmFtZSBjaGFpbmluZyBjaGVja3Mg
aW4gcGF0aCB2YWxpZGF0aW9uDQo+IG5lZWRzIHRvIGhhdmUgdGhlaXIgZXllcyBjaGVja2VkLiBS
RkMgMzI4MCBzYXlzIGluIG1hbnkNCj4gcGxhY2VzIHRoYXQgbmFtZSBjaGFpbmluZyBNVVNUIGJl
IGNoZWNrZWQuDQo+IA0KPiBJbiBzZWN0aW9uIDYuMToNCj4gDQo+ICBUbyBtZWV0IHRoaXMgZ29h
bCwgdGhlIHBhdGggdmFsaWRhdGlvbiBwcm9jZXNzIHZlcmlmaWVzLCBhbW9uZyBvdGhlcg0KPiB0
aGluZ3MsIHRoYXQgYSBwcm9zcGVjdGl2ZSBjZXJ0aWZpY2F0aW9uIHBhdGggKGEgc2VxdWVuY2Ug
b2Ygbg0KPiAgY2VydGlmaWNhdGVzKSBzYXRpc2ZpZXMgdGhlIGZvbGxvd2luZyBjb25kaXRpb25z
Og0KPiANCj4gICAgIChhKSAgZm9yIGFsbCB4IGluIHsxLCAuLi4sIG4tMX0sIHRoZSBzdWJqZWN0
IG9mIGNlcnRpZmljYXRlIHggaXMNCj4gICAgIHRoZSBpc3N1ZXIgb2YgY2VydGlmaWNhdGUgeCsx
Ow0KPiANCj4gSW4gc2VjdGlvbiA2LjEuMzoNCj4gDQo+ICAoYSkgIFZlcmlmeSB0aGUgYmFzaWMg
Y2VydGlmaWNhdGUgaW5mb3JtYXRpb24uICBUaGUgY2VydGlmaWNhdGUgIE1VU1QNCj4gc2F0aXNm
eSBlYWNoIG9mIHRoZSBmb2xsb3dpbmc6DQo+IA0KPiAgWy4uLl0NCj4gDQo+ICAgICAoNCkgIFRo
ZSBjZXJ0aWZpY2F0ZSBpc3N1ZXIgbmFtZSBpcyB0aGUgd29ya2luZ19pc3N1ZXJfbmFtZS4NCj4g
DQo+IEluIHNlY3Rpb24gNC4xLjIuNjoNCj4gDQo+ICAgIElmIHRoZSBzdWJqZWN0IGlzIGEgQ0Eg
KGUuZy4sIHRoZSBiYXNpYyBjb25zdHJhaW50cyBleHRlbnNpb24sIGFzDQo+ICAgIGRpc2N1c3Nl
ZCBpbiA0LjIuMS4xMCwgaXMgcHJlc2VudCBhbmQgdGhlIHZhbHVlIG9mIGNBIGlzIA0KPiBUUlVF
KSwgdGhlbg0KPiAgICB0aGUgc3ViamVjdCBmaWVsZCBNVVNUIGJlIHBvcHVsYXRlZCB3aXRoIGEg
bm9uLWVtcHR5IGRpc3Rpbmd1aXNoZWQNCj4gICAgbmFtZSBtYXRjaGluZyB0aGUgY29udGVudHMg
b2YgdGhlIGlzc3VlciBmaWVsZCAoc2VjdGlvbiA0LjEuMi40KSBpbg0KPiAgICBhbGwgY2VydGlm
aWNhdGVzIGlzc3VlZCBieSB0aGUgc3ViamVjdCBDQS4NCj4gDQo+IFJGQyAyNDU5IGFuZCBYLjUw
OSBib3RoIGFncmVlIHdpdGggdGhpcy4NCj4gDQo+IFdoYXRldmVyIFBLSSB0b3BvbG9neSB5b3Ug
dXNlLCB0aGVyZSdzIG5vIG5lZWQgdG8gYnJlYWsNCj4gbmFtZSBjaGFpbmluZy4gSSdtIHN1cmUg
dGhhdCBzb21lIGN1c3RvbWVycyBoYXZlIGNyZWF0ZWQNCj4gUEtJcyB3aGVyZSBuYW1lIGNoYWlu
aW5nIGRvZXNuJ3QgaG9sZCwgYnV0IHRoYXQncyBhbiBlcnJvcg0KPiBvbiB0aGUgY3VzdG9tZXIn
cyBwYXJ0LiBZb3UgY2FuJ3QganVzdCB0dXJuIG9mZiBjcml0aWNhbCANCj4gc2VjdXJpdHkgY2hl
Y2tzDQo+IHRvIGtlZXAgdGhlbSBoYXBweS4gV2hhdCdzIG5leHQ/IERvbid0IGJvdGhlciBjaGVj
a2luZyB0aGUgDQo+IHNpZ25hdHVyZSBvbg0KPiBjZXJ0aWZpY2F0ZXMuIFRoYXQgdGFrZXMgdG9v
IG11Y2ggdGltZSENCj4gDQo+IElmIHNvbWVib2R5IGhhcyBpbXBsZW1lbnRlZCBwYXRoIHZhbGlk
YXRpb24gd2l0aG91dCBuYW1lIA0KPiBjaGFpbmluZyBjaGVja3MsDQo+IHRoZW4gdGhleSBoYXZl
bid0IGltcGxlbWVudGVkIGl0IGFjY29yZGluZyB0byBJRVRGIG9yIFguNTA5IA0KPiBzdGFuZGFy
ZHMuIEluDQo+IGZhY3QsIHRoZXkgbWF5IGhhdmUgb3BlbmVkIHRoZW1zZWx2ZXMgYW5kIHRoZWly
IGN1c3RvbWVycyB1cCANCj4gdG8gc2VjdXJpdHkNCj4gaG9sZXMgYW5kIHBlcmhhcHMgZXZlbiBs
ZWdhbCBsaWFiaWxpdHkuIENBcyBoYXZlIGV2ZXJ5IHJpZ2h0IHRvIGV4cGVjdA0KPiB0aGF0IGNl
cnRpZmljYXRlcyB3aWxsIGJlIHZhbGlkYXRlZCBhY2NvcmRpbmcgdG8gc3RhbmRhcmRzLiBVc2Vy
cyBhbHNvDQo+IGhhdmUgYSByZWFzb25hYmxlIGV4cGVjdGF0aW9uIG9mIHRoaXMuIElmIHNvbWVv
bmUgDQo+IGRlbGliZXJhdGVseSB2aW9sYXRlcw0KPiB0aGUgc3RhbmRhcmRzIGluIGEgd2F5IHRo
YXQgb3BlbnMgdXAgc2VjdXIEggceaXR5IGhvbGVzLCB0aGF0IHNvdW5kcyBsaWtlDQo+IGdyb3Nz
IG5lZ2xpZ2VuY2UgdG8gbWUuDQo+IA0KPiBUaGlzIHJlbWluZHMgbWUgb2YgTWljcm9zb2Z0J3Mg
ZGVjaXNpb24gdG8gbm90IGNoZWNrIHRoZQ0KPiBCYXNpYyBDb25zdHJhaW50cyBleHRlbnNpb24s
IHRyZWF0aW5nIGV2ZXJ5IGNlcnRpZmljYXRlDQo+IGFzIGEgQ0EgY2VydGlmaWNhdGUuIFRoaXMg
ZGVjaXNpb24sIHByZXN1bWFibHkgbWFkZSBpbg0KPiB0byBwbGVhc2UgYSBjdXN0b21lciwgcmVz
dWx0ZWQgaW4gYSBIVUdFIHNlY3VyaXR5IGhvbGUuDQo+IA0KPiBJIGhvcGUgdGhhdCBNaWNyb3Nv
ZnQgKGFuZCBhbnlvbmUgZWxzZSB3aG8gaGFzIHNraXBwZWQNCj4gcmVxdWlyZWQgcGFydHMgb2Yg
dGhlIHBhdGggdmFsaWRhdGlvbiBhbGdvcml0aG0gZm9yIHRoZQ0KPiBzYWtlIG9mIGNvbnZlbmll
bmNlKSB3aWxsIHNlZSB0aGF0IHNlY3VyaXR5IGNhbm5vdCBiZQ0KPiBzZWNvbmQgdG8gdXNlciBj
b252ZW5pZW5jZS4gSWYgdGhlcmUncyBhIHNlcmlvdXMgcHJvYmxlbQ0KPiB3aXRoIHRoZSBzcGVj
cywgdGhlbiBsZXQncyBmaXggdGhlbS4gQnV0IGRvbid0IGp1c3QgYnlwYXNzIA0KPiB0aGluZ3Mg
YmVjYXVzZQ0KPiB5b3UgZmluZCBpdCBjb252ZW5pZW50Lg0KPiANCj4gRm9yZ2l2ZSBtZSBteSBy
YW50LiBJJ20ganVzdCBvdXRyYWdlZCB0aGF0IHNvbWVib2R5IHdvdWxkDQo+IHBsYXkgZmFzdCBh
bmQgbG9vc2Ugd2l0aCBzZWN1cml0eSB0aGlzIHdheS4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IFN0
ZXZlDQo+IA0KPiBQZXRlciBHdXRtYW5uIHdyb3RlOg0KPiA+DQo+ID4gW0Nyb3NzLXBvc3RlZCBi
YWNrIHRvIFMvTUlNRSwgd2hlcmUgdGhlIHRocmVhZCBzdGFydGVkXQ0KPiA+DQo+ID4gRXJpYyBO
b3JtYW4gPGVqbm9ybWFuQGRvaXQud2lzYy5lZHU+IHdyaXRlczoNCj4gPg0KPiA+ID5JcyB0aGVy
ZSBhIGNsYWltICgjMSBhYm92ZSkgdGhhdCB5b3UgY2FuIGhhdmUgdGhlIEROIGluIHRoZSBzdWJq
ZWN0DQo+ID4gPm9mIGEgcGFyZW50J3MgKHNpZ25lcidzKSBjZXJ0aWZpY2F0ZSBiZSBkaWZmZXJl
bnQgZnJvbSAoYXMgaW4NCj4gPiA+ZGlmZmVyZW50IGJ1bmNoIG9mDQo+ID4gPmJ5dGVzKSB0aGUg
RE4gaW4gdGhlIGlzc3VlciBvZiBvbmUgb2YgaXRzIG9mZnNwcmluZyBhbmQgDQo+IHlldCB0aGUg
Y2hhaW4NCj4gaXMNCj4gPiA+c3RpbGwgdmFsaWQgYmVjYXVzZSB0aGUgeEtJRHMgbWF0Y2g/DQo+
ID4NCj4gPiBTdXJlLCBpbiBhIHNwYWdoZXR0aSBQS0kgKEknbSB1c2luZyB0aGF0IGFzIGEgZ2Vu
ZXJpYyB0ZXJtIGZvciBhIFBLSQ0KPiA+IHRoYXQgdmlvbGF0ZXMgdGhlIG9yaWdpbmFsIFguNTA5
IGRlc2lnbiwgaS5lLiB3aXRoIHJlLXBhcmVudGluZywNCj4gPiBhcmJpdHJhcnkgY3Jvc3MtIGNl
cnRpZmljYXRpb24sIGV0YyBldGMgd2hlcmUgaXNzdWVycyBubyANCj4gbG9uZ2VyIG1hdGNoDQo+
ID4gc3ViamVjdHMpLiAgRm9yIGV4YW1wbGUgTVMgYXBwYXJlbnRseSBpbXBsZW1lbnRlZCBjaGFp
bmluZyANCj4gYnkgc0tJRCBpbg0KPiA+IFdpbmRvd3MgYmVjYXVzZSBvZiB1c2VyIGRlbWFuZCBm
b3IgdGhpcyB3aGVuIHRoZSB1c2VycyANCj4gYnJva2UgY2hhaW5pbmcNCj4gPiBieSBpc3N1ZXIg
bmFtZSB0aHJvdWdoIHNwYWdoZXR0aSBQS0kgZGVzaWduIHByYWN0aWNlcywgYW5kIHZhcmlvdXMN
Cj4gPiBvdGhlciBpbXBsZW1lbnRhdGlvbnMgbm8gZG91YnQgZG8gc2ltaWxhciB0aGluZ3MsIGRl
cGVuZGluZyBvbiBob3cNCj4gPiB0aGV5J3ZlIHJlYWQgdGhlIFBLSVggdGVhIGxlYXZlcy4NCj4g
Pg0KPiA+IFBldGVyLg0KPiANCgAAAAAAAKCCBugwggNgMIICSKADAgECAgJQLTANBgkqhkiG9w0B
AQUFADBPMQswCQYDVQQGEwJBVTESMBAGA1UEChMJQmFsdGltb3JlMQwwCgYDVQQLEwNEZXYxHjAc
BgNVBAMTFVRvbSdzIFJlbmV3YWwgVGVzdCBDQTAeFw0wMzEwMDgwNTIwNTlaFw0wNDA4MTgwODM3
MDRaMHIxCzAJBgNVBAYTAkFVMQwwCgYDVQQIEwNOU1cxDzANBgNVBAcTBlN5ZG5leTEfMB0GA1UE
ChMWQmFsdGltb3JlIFRlY2hub2xvZ2llczEMMAoGA1UECxMDRGV2MRUwEwYDVQQDEwxUb20gQmlz
a3VwaWMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALPa7g0wfcfcG8C1Yews0f9UtN9VmMe7
W4szYbMfKTK0wVrUekeZw5ItMtg02szCVA5oZKGYJsZ0FVUB8daNVJ/O8Dp5wXAFgeJsVkCdANUn
Q8juzLBknroTBtKZHj4lehE6n8+c8999a8vAIejE4ZCsWJGwEBsElHJfP7cvCxsJAgMBAAGjgaYw
gaMwCQYDVR0TBAIwADAlBgNVHREEHjAcgRp0b20uYmlza3VwaWNAYmFsdGltb3JlLmNvbTALBgNV
HQ8EBAMCBaAwYgYDVR0jBFswWaFTpFEwTzELMAkGA1UEBhMCQVUxEjAQBgNVBAoTCUJhbHRpbW9y
ZTEMMAoGA1UECxMDRGV2MR4wHAYDVQQDExVUb20ncyBSZW5ld2FsIFRlc3QgQ0GCAgICMA0GCSqG
SIb3DQEBBQUAA4IBAQAl72UKyGwSuluRLQYBA68P+T4RZTU9XnfujmZ24Q9yN+TbQ/+9vb8Of9RY
Hfx6iuPRyqOaIhtLOK2ECBKcmoK+l7TKJczvmh56sIXz5nwg1+zkTm19Zsm8mJlv81l2cOcKDyIf
r+Hwx3Yn1HS4B3tuFhMQtZ962lp26uVbOg4Eq7UTsKmu4wJePIx0cjLT0a+E7QaSNmPy90niZh55
JOpzKRHFWfqrlTFakjd8DY/R+erxLMLSQDu3EzYnnW6Rq3eRHXTLr+8Lx3HhTmy6lnBlxTIFFgGr
854ZTtISxw5UxjsqPj66nLRSgg9zTxz0auSTepH3Qhd2Nc+A2xl8a+5uMIIDgDCCAmigAwIBAgIC
AgIwDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCQVUxEjAQBgNVBAoTCUJhbHRpbW9yZTEMMAoG
A1UECxMDRGV2MR4wHAYDVQQDExVUb20ncyBSZW5ld2FsIFRlc3QgQ0EwHhcNMDMwODE4MDgzNzA0
WhcNMDQwODE4MDgzNzA0WjBPMQswCQYDVQQGEwJBVTESMBAGA1UEChMJQmFsdGltb3JlMQwwCgYD
VQQLEwNEZXYxHjAcBgNVBAMTFVRvbSdzIFJlbmV3YWwgVGVzdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBALVrtYeqs2BRAawjhpOXUx0LzlUsl2QUHMESRpLDXSnH5QUN+n/v6VM8
jz+YMhNw9y6hmJvb55n5GH/zFNeoGWnd/bXkSiJdg01fGdgyNl6NUfq+1UfM+sANG3rC5fZq9+U7
RB9DX5hbOIe/kSRQY14+UiKR4e6x1P+NwhvOwA11mB7eTlLlnr/mH0vq9rRjfUuwHvewf07QxqVm
yFG/lzpa6aDH3frx/kMN0nr2qb1Ag1p9TWt2b4hh9iL4WsTQQxfNQfz9oW7q1gTsVsQk0e4GZD0K
+V4mNtd8y9Z1xAi4dR1qnhFnkKOIkagh6GyT+8Hp4Kj69A062/z7Oqlr8zcCAwEAAaNmMGQwIgYD
VR0RBBswGYEXdGJpc2t1cGljQGJhbHRpbW9yZS5jb20wEgYDVR0TAQH/BAgwBgEB/wIBAzALBgNV
HQ8EBAMCAgQwHQYDVR0OBBYEFMfnNaRJJyOBLnSp2vUWZVE6BolIMA0GCSqGSIb3DQEBBQUAA4IB
AQBV/0ledh1T2fSZx7sXBWSDYwQV2ulp3Q8n23Wjiy9Vvt0jJid6Tl30lTzBPuJdYe8z+DZazCR4
Onak+EPmSXGRYtmxRFZDz40RotA6VxCUSDlOr2MZBSRjlEJehcek1FaJ3TKLoHK+mcG6Dldj5+eN
z5L0uQ+f8NmDVY9qBHcHDqFhG9n37CHQaoHc8Xtp6VJYP5i2mSqfbyogvUgroaOnxmVSQwckW6Vb
wHQv+Mic8dQuybyXsB641SaqswTEdHrxnbHikoRPcYuoPLAU9h9SIIFYho7yZd3lp59g6OQqyyk/
2Plcmt1nnUbB/I4vr9s2yjy6LZNaIV9ktcerIk8oMYICHDCCAhgCAQEwVTBPMQswCQYDVQQGEwJB
VTESMBAGA1UEChMJQmFsdGltb3JlMQwwCgYDVQQLEwNEZXYxHjAcBgNVBAMTFVRvbSdzIFJlbmV3
YWwgVGVzdCBDQQICUC0wCQYFKw4DAhoFAKCCAR0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc
BgkqhkiG9w0BCQUxDxcNMDMxMDMwMDYzNzI2WjAjBgkqhkiG9w0BCQQxFgQUOEFS5L/24mULv+Bx
eyMIryqrcEkwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwZAYJKwYBBAGCNxAEMVcw
VTBPMQswCQYDVQQGEwJBVTESMBAGA1UEChMJQmFsdGltb3JlMQwwCgYDVQQLEwNEZXYxHjAcBgNV
BAMTFVRvbSdzIFJlbmV3YWwgVGVzdCBDQQICUC0wDQYJKoZIhvcNAQEBBQAEgYBzeYIKDpiOpM5Z
i7QPZJSe+J6UoQYl2LOurDlq+sm1R6Vw84tGSA0uXoDUnSbrmeNymU6FWpDWz4LEjTk/JQhFh+qa
NSDoy6bMp4VlbonPi+dTWYAK8dAnjlEZ8X2OS7uYIl/JfcOCDIdiNsgOMZFv6F5uTkibjbcE6ONi
QLQ4+wAAAAAAAA==


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U42skT064263 for <[e-mail]>; Wed, 29 Oct 2003 20:02:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U42sFw064262 for ietf-pkix-bks; Wed, 29 Oct 2003 20:02:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U42qkT064257; Wed, 29 Oct 2003 20:02:53 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9U42no9019708; Thu, 30 Oct 2003 17:02:49 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9U45FK16114; Thu, 30 Oct 2003 17:05:15 +1300
Date: Thu, 30 Oct 2003 17:05:15 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Request change in son-of-rfc2633
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna <[e-mail]> writes:

>Anyone who "reads the PKIX tea leaves" and thinks that it's fine to skip name 
>chaining checks in path validation needs to have their eyes checked. RFC 3280 
>says in many places that name chaining MUST be checked.

Uhh, I'm not sure who that was directed at, but if it was at me then I should 
point out that the tea leaves comment was an observation that no-one seemed to 
be able to agree on the role of the sKID, with all manner of possible 
interpretations having been presented in the recent thread.  Seeing everyone 
trying to figure out how to interpret the sKID requirements reminded me of 
people trying to read tea leaves.

Getting somewhat more tongue-in-cheek now:

>I'm sure that some customers have created PKIs where name chaining doesn't 
>hold, 

Standard practice for cross-certification, re-parenting, and all the other 
stuff that I gave the generic label "spaghetti PKI" to (you can tell from the 
label I use for it what I think of it :-).

>but that's an error on the customer's part.

That's what I've been saying for years (see e.g. my statement a couple of months
back "There is a special name for a PKI of this kind.  It's called 'Broken' or
'Defective'"), but I guess that's something the spaghetti PKI fans and myself 
will have to agree to disagree on.

>In fact, they may have opened themselves and their customers up to security 
>holes and perhaps even legal liability.

When was anyone ever held liable for implementing a broken PKI?  Usually any 
investment of large amounts of money that results in a broken PKI is followed 
by the investment of even more money in it (either that or the quiet 
cancellation of the project).  No-one ever gets held liable.  Why do you think
we have products like the ones you mentioned out there?

>This reminds me of Microsoft's decision to not check the Basic Constraints 
>extension, treating every certificate as a CA certificate. This decision, 
>presumably made in to please a customer, resulted in a HUGE security hole.

It wasn't a conscious decision, just bad programming.  Mozilla (and no doubt 
some others that didn't get any publicity) did the same thing, and I'm sure 
they didn't get asked to do that by customers.  The flaw had been known for at 
least five years, but no-one cared until the scaremongering in the media forced 
vendors to fix things (see the above comments about liability - you can get 
away with calling anything you like "X.509 standards-compliant", so why bother 
doing the job properly?).

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U2VxkT061240 for <[e-mail]>; Wed, 29 Oct 2003 18:31:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U2VxX1061239 for ietf-pkix-bks; Wed, 29 Oct 2003 18:31:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U2VwkT061219 for <[e-mail]>; Wed, 29 Oct 2003 18:31:58 -0800 (PST) (envelope-from [e-mail])
Received: from [12.159.173.168] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h9U2Vslo014559; Wed, 29 Oct 2003 21:31:55 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06002001bbc626ccb55d@[12.159.173.168]>
In-Reply-To: <00a801c39e39$cf4a1890$791a40d5@arport>
References: <001601c39e09$25d69520$4228a8c0@hagen> <01e801c39e1d$7c6cc850$651a40d5@arport> <p06002001bbc58537e2cb@[128.33.244.157]> <00a801c39e39$cf4a1890$791a40d5@arport>
Date: Wed, 29 Oct 2003 21:26:12 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Standards for Web-signing II
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 17:29 +0100 10/29/03, Anders Rundgren wrote:
>  >since you obviously don't believe the IETF creates "real standards"
>>and since this topic is not a PKIX work item, I suggest you take the
>>"web-sigbing" discussion elsewhere.
>
>As the off-list response to "web-signing" has been pretty good, I
>just need to figure out where to go next.
>
>You did probably not read more than the first paragraph.  To go
>through a "real standardization process" was ONE of the stated
>alternatives.
>
>Anders

if your off-list response was so good, then you should have no 
trouble moving this discussion elsewhere.

I read all of the traffic re the subject topic, and as I noted, it is 
off topic for this WG, as have been most of your messages threads.

steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKrRkT043915 for <[e-mail]>; Wed, 29 Oct 2003 12:53:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TKrRQA043914 for ietf-pkix-bks; Wed, 29 Oct 2003 12:53:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKrNkT043895; Wed, 29 Oct 2003 12:53:26 -0800 (PST) (envelope-from [e-mail])
Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by mclean-vscan2.bah.com (8.11.0/8.11.0) with SMTP id h9TKqgM13536; Wed, 29 Oct 2003 15:52:42 -0500 (EST)
Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan2.bah.com (NAVGW 2.5.2.12) with SMTP id M2003102915503623002 ; Wed, 29 Oct 2003 15:50:36 -0500
Received: from wchokhani ([156.80.127.102]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HNJDWE00.KHV; Wed, 29 Oct 2003 15:50:38 -0500 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Request change in son-of-rfc2633
Date: Wed, 29 Oct 2003 15:50:35 -0500
MIME-Version: 1.0
Message-ID: <006401c39e5e$4d7280d0$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0060_01C39E1C.EE435990"
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

Steve Hanna:

I agree with you that both 3280 and X.509 require name chaining.  However,
the security implications and security importance of name chaining is
overstated.

For example, if signatures chain properly for the certificate and CRL and
the relying party has appropriate means (e.g., e-mail address) to identify
the subscriber, name chaining offers little in terms of security.

My statement should be read purely in security (and NOT interoperability)
context.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Steve Hanna
Sent: Wednesday, October 29, 2003 9:58 AM
To: Peter Gutmann
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Request change in son-of-rfc2633


Anyone who "reads the PKIX tea leaves" and thinks that
it's fine to skip name chaining checks in path validation
needs to have their eyes checked. RFC 3280 says in many
places that name chaining MUST be checked.

In section 6.1:

 To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n
 certificates) satisfies the following conditions:

    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
    the issuer of certificate x+1;

In section 6.1.3:

 (a)  Verify the basic certificate information.  The certificate  MUST
satisfy each of the following:

 [...]

    (4)  The certificate issuer name is the working_issuer_name.

In section 4.1.2.6:

   If the subject is a CA (e.g., the basic constraints extension, as
   discussed in 4.2.1.10, is present and the value of cA is TRUE), then
   the subject field MUST be populated with a non-empty distinguished
   name matching the contents of the issuer field (section 4.1.2.4) in
   all certificates issued by the subject CA.

RFC 2459 and X.509 both agree with this.

Whatever PKI topology you use, there's no need to break
name chaining. I'm sure that some customers have created
PKIs where name chaining doesn't hold, but that's an error
on the customer's part. You can't just turn off critical security checks
to keep them happy. What's next? Don't bother checking the signature on
certificates. That takes too much time!

If somebody has implemented path validation without name chaining checks,
then they haven't implemented it according to IETF or X.509 standards. In
fact, they may have opened themselves and their customers up to security
holes and perhaps even legal liability. CAs have every right to expect
that certificates will be validated according to standards. Users also
have a reasonable expectation of this. If someone deliberately violates
the standards in a way that opens up security holes, that sounds like
gross negligence to me.

This reminds me of Microsoft's decision to not check the
Basic Constraints extension, treating every certificate
as a CA certificate. This decision, presumably made in
to please a customer, resulted in a HUGE security hole.

I hope that Microsoft (and anyone else who has skipped
required parts of the path validation algorithm for the
sake of convenience) will see that security cannot be
second to user convenience. If there's a serious problem
with the specs, then let's fix them. But don't just bypass things because
you find it convenient.

Forgive me my rant. I'm just outraged that somebody would
play fast and loose with security this way.

Thanks,

Steve

Peter Gutmann wrote:
>
> [Cross-posted back to S/MIME, where the thread started]
>
> Eric Norman <[e-mail]> writes:
>
> >Is there a claim (#1 above) that you can have the DN in the subject
> >of a parent's (signer's) certificate be different from (as in
> >different bunch of
> >bytes) the DN in the issuer of one of its offspring and yet the chain
is
> >still valid because the xKIDs match?
>
> Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI
> that violates the original X.509 design, i.e. with re-parenting,
> arbitrary cross- certification, etc etc where issuers no longer match
> subjects).  For example MS apparently implemented chaining by sKID in
> Windows because of user demand for this when the users broke chaining
> by issuer name through spaghetti PKI design practices, and various
> other implementations no doubt do similar things, depending on how
> they've read the PKIX tea leaves.
>
> Peter.

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUqTCCA9Yw
ggK+oAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9u
IFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFjAUBgNVBAMTDU9yaW9uIFJvb3QgQ0Ew
HhcNMDMwODEzMTcwMTI0WhcNMTMwODEwMTcwMTI0WjBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMY
T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9v
dCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOd3fg/nIELr3rAuxpkcxiAn7ayU
/30RPxYBMgcvn0BJbBXBXIkTHgm3jh0TwHGQk76nqTSo1fUqpkkEcSSwEtfz1jF0QCKPHoQvNxza
5ffqH2gBSTgjpwqLA34RDxFDwcdNibIG/s6Zj2PpVDDWVBYxMbLrhKluMAfufhOMT6uyYxw+XPcU
ndqy4bRo08BONIoLdoUoOsvOwHla+zPYsBnTncMEL26lnKgCQgJpcFfrQRLrM84Rlc9EmvPbU+tO
5jRfdnvJpCm8LbIcTvAwQLiM+5qr4GPTg73S+9ZMAjlaZWG/VGe5b+KtQCgDu2TPB+wtiz2csG5q
YN14mFpKMdMCAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV
HQ4EFgQUvpoqeR5tpH+G2bn1P06LoHH9Mq0wHwYDVR0jBBgwFoAUvpoqeR5tpH+G2bn1P06LoHH9
Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25z
ZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAch1imNzh8/wx6Ym3ti6FI
LyJMsktilc4I5zJ6ZRrZUMye/3v9XJDIutBPb472wOwQT+OR3DTbWX8loNybf3Ew3wWzZg+D14kQ
d/+rm3ZAJ3EeX67/g9XevAkrv951Q7QSucZMbbzrLqIWSkgjxJbcujNdeQsSlUz5I2Q9qYdAhg6G
85gf+GaStpaGlR5siWwJAQ/KeWrntfwNbh1P81Vmq/MovUQWPNKeM80FHcqHVVpQWasPTkGb0eW2
NOBsxGBCSQjc5QQdxPIMIuxmyVX42kGTK3O/IxI2O2QBK+pmFHEm4o+p+ekxxHekZTowPSeFXFYQ
SrnpmJyfcHa2vLTpMIID1zCCAr+gAwIBAgIBAjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJV
UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UE
AxMNT3Jpb24gUm9vdCBDQTAeFw0wMzA4MTQxNjQ4MzZaFw0wNDA4MTMxNjQ4MzZaMFYxCzAJBgNV
BAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxCzAJBgNVBAsTAkhRMRcw
FQYDVQQDEw5PcmlvbiBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL65
aM5ISSZ1ERaIjEaBDvZJ+U1iEEvdLoILkmuwzqrN0DMNhBwLUPJSYjGZ6xlGE5sRmDbUcFhRX0Dt
p/t0lKBl0zajquPRbO5t3whqhb0h5IgIRP19NOZ9Mo/XWML2eCVmDyy6lqK5NC+Uvdhf8SjjH+P2
WCk68KmELfqXSfHoKy9gKMEH9IFyL1EqbE8DTUuFmUzg3ZIpR9UMX0Yorx4YdQRyblH4fEUDNfUu
PHvRTZkyfAm8nrpsWCqOY0Q3Vl6OsfMqBaVYOORA9fDPLZLXvYc7Im3LDTAXvy+DTki2cR3rjLrO
+p3POH/SoH8/9eHhNk4fX/w4FvQMv9hIonECAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4G
A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU+NvSaD0SiHYB9QkgqlK4n+fFAKEwHwYDVR0jBBgwFoAU
vpoqeR5tpH+G2bn1P06LoHH9Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiG
Jmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IB
AQDPS+PvtkWJ6V235n4Ntn5xWFgvS+GVMI3tBVid/DW2h3AxDWzKctlybc/FhO0sj7nlLXE5CQfm
ocx7m3mf1DcEz83b3BJNO9Dwa0U1kNL0kAFSXb9i+jaL3ovNoZlXxOcl73dK77eEohYbioUOtglM
HwXXOdbpbOPH1tX0fUr70Zp4KBczNdsQnSrbnHIe2zdNPKY5VPYonB6gxJTNxlbqcHYg56abe0En
Ad0C5IoMEG13CbHfDCm9uhRC5yHfylEZMOYA644+2d73FUsIstAdwK+pyeWXSaWGwN/xgLAGE5S1
Ryihlql/q4BXxqqU8RPm90g+2aj1e+PlnlXHxLWCMIID2jCCAsKgAwIBAgIBADANBgkqhkiG9w0B
AQUFADBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQsw
CQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9vdCBDQTAeFw0wMzA2MDUxNDI4NTlaFw0wNDA2
MDQxNDI4NTlaMFYxCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlv
bnMxCzAJBgNVBAsTAkhRMRcwFQYDVQQDEw5PcmlvbiBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAL65aM5ISSZ1ERaIjEaBDvZJ+U1iEEvdLoILkmuwzqrN0DMNhBwLUPJS
YjGZ6xlGE5sRmDbUcFhRX0Dtp/t0lKBl0zajquPRbO5t3whqhb0h5IgIRP19NOZ9Mo/XWML2eCVm
Dyy6lqK5NC+Uvdhf8SjjH+P2WCk68KmELfqXSfHoKy9gKMEH9IFyL1EqbE8DTUuFmUzg3ZIpR9UM
X0Yorx4YdQRyblH4fEUDNfUuPHvRTZkyfAm8nrpsWCqOY0Q3Vl6OsfMqBaVYOORA9fDPLZLXvYc7
Im3LDTAXvy+DTki2cR3rjLrO+p3POH/SoH8/9eHhNk4fX/w4FvQMv9hIonECAwEAAaOBszCBsDAS
BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU+NvSaD0SiHYB9Qkg
qlK4n+fFAKEwHwYDVR0jBBgwFoAUvpoqeR5tpH+G2bn1P06LoHH9Mq0wEQYJYIZIAYb4QgEBBAQD
AgAHMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX3Jvb3Qu
Y3JsMA0GCSqGSIb3DQEBBQUAA4IBAQCxgp0tv87jUcjW/N8p+FgFn6+vBZQ80DhtLSYfi1KGBgQn
kjXk1dgr6zPiBtfow/eyXCn7C2kErJIwwXbNv93s7N3ntpgh7DMD9A6I69zKTeMvzn4K2SCQ718s
Hhk9mTKceIj7joDG6KZ7lw2COiFx/oEUehRF6i601u9h8mHJ5HPpoAD+QyzBHfkmN6njulLYmY5W
8omXRl4fPZdWu3TNRPemxY859PrZiqrVjogqXOH7ceBttkQ1PnjLxZV0PKgyiAhzgBwWf+dkjWxq
NJtwJjGLntm+vVYpTbXuyY63U41rzEckGNOWdMoR8zwupTGmT1j5cNXkccGExpqnf2pbMIIEdzCC
A1+gAwIBAgIBIjANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24g
U2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwgQ0Ew
HhcNMDMwODE1MTgyMDM3WhcNMDQwODE0MTgyMDM3WjB+MQswCQYDVQQGEwJVUzEhMB8GA1UEChMY
T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEZMBcGA1UEAxMQU2FudG9zaCBD
aG9raGFuaTEkMCIGCSqGSIb3DQEJARYVY2hva2hhbmlAb3Jpb25zZWMuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0EadobvmWyC1UbtEuos8DmEK7vsk72z3USFc4MF4I71ctasT
uT7n3eY0RsXK5NSrGNufwwup7ksdZAo/a6GPxiGMDOaQtJi8VaACzPUyqzZZJEKtaolcD4fS8V6O
FyBdMmdMBebd0GrcNVmabvgVIm3h5Oe3sUzZxqkduueAkjMstGnBtUWG431HzM3vOTzkbHzkMoNT
FgMEayhHrklyecveHOgiqhOypAiKSv5acM2vgzreh5gbHEJfqOfS56+exTAz/MrpdzvXmv0kmrwM
BOtTM1rOYhyjw2yzM07lBxstBMR0DIeqpf2dZN1IHOnnGWxSqql2Gdjn9bpplVN2EQIDAQABo4IB
JjCCASIwHQYDVR0OBBYEFPQLCXgNtykUjPyCwMO9MWrT0A86MB8GA1UdIwQYMBaAFPjb0mg9Eoh2
AfUJIKpSuJ/nxQChMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29y
aW9uX21haWwuY3JsMAkGA1UdEwQCMAAwQgYIKwYBBQUHAQEENjA0MDIGCCsGAQUFBzAChiZodHRw
Oi8vd3d3Lm9yaW9uc2VjLmNvbS9vcmlvbl9tYWlsLmRlcjAOBgNVHQ8BAf8EBAMCBDAwEwYDVR0l
BAwwCgYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgWgMCAGA1UdEQQZMBeBFWNob2toYW5pQG9y
aW9uc2VjLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAOMNwcRoKaH2+5wC7MWhDrG98bOyphlE51btw
mPHS9Ob5XpJMJMlZI2kb2/4A71riaZZPcuFypMqxGIjaH7Y/Gi0aHsk7iWRMEMXiaCT2fq0WM1Wq
/sDgwMYVCvOjU8s5x+4i7y4tvS/eP01qcmqz5RABM85bmZ45qypM+JV246LxYRkVpESl62+iSkcg
U8hmtruiV7C8CX3yUZj//uwPH9F+7iwvSEAmH6vm4MxGxrMbo2yThsvJ6KNZ1XVlT3jtA66AhoKB
h++f7KfuqJbWUaQXVuvGESCHI79DCtXVUK7YFdHQxLU1Y63NkqRYTncrHtJlqzY2kxq5B/0vnPhg
1zCCBJcwggN/oAMCAQICASEwDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxITAfBgNVBAoT
GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVt
YWlsIENBMB4XDTAzMDgxNTE4MjAxN1oXDTA0MDgxNDE4MjAxN1owfjELMAkGA1UEBhMCVVMxITAf
BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExGTAXBgNVBAMTEFNh
bnRvc2ggQ2hva2hhbmkxJDAiBgkqhkiG9w0BCQEWFWNob2toYW5pQG9yaW9uc2VjLmNvbTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMLUZwZhoWYVw7zKNe5KLxQfXo0dKMKkph9MA+fN
X9YPW/LEbsjqdofCRJ1F8VZalpBrlz61ITyJ7/y+W1My0n0oOJhwvdhqRxE2QUv+bOP80i7BGqIm
4/wd35ZyABDG2mt5Jj2anwXUIK1KENCo1pYxhroil3qLhtd9xPiOOjUZ2wAmNEgFwxDcQE1xsNJt
J3Ro1O3VfceF53AxomEIZM300usixqnUSKbk8D8oVwUNBnMXdj+7K/0G/YJ9EPJFF5orwI1j9LE3
tdWBVY9a7WY1+ygHDMXaeYAnM2TkAuVGtWqTHTGmdNuyxsapFY7UFLtRjItA2oFb3bs/ho1tKrUC
AwEAAaOCAUYwggFCMB0GA1UdDgQWBBQSo0Fab6xpwZ5BxERoEuUigr/N2zAfBgNVHSMEGDAWgBT4
29JoPRKIdgH1CSCqUrif58UAoTA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3Lm9yaW9uc2Vj
LmNvbS9vcmlvbl9tYWlsLmNybDAJBgNVHRMEAjAAMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcw
AoYmaHR0cDovL3d3dy5vcmlvbnNlYy5jb20vb3Jpb25fbWFpbC5kZXIwDgYDVR0PAQH/BAQDAgbA
MDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQBgjcUAgIwEQYJ
YIZIAYb4QgEBBAQDAgWgMCAGA1UdEQQZMBeBFWNob2toYW5pQG9yaW9uc2VjLmNvbTANBgkqhkiG
9w0BAQUFAAOCAQEAmnUXuCAU2nzNbCAaRmH0JE1bFUr/bNPUoOHU7ATGfmk/QhiGPxaApPSU+CC8
JNgGOs6z6o/WCfKMj4srMkWjBKcFHNASw7oxsLdEj/JvIAcPVPwfV4RUBY7SU3svNPQILSYdD0LU
uhryAqMlNePrDPi5LWSyJ1q4ftRtZZlJdu50UjBSPwJcOhrn4CJAzu4DHRAWNLvVZ91m7c/E6LF4
Ajj1QC8Sd2HWpgc0iQf7XAN58+7Y9fF+F6VebVeuLws2IZNPfdTvq+1kHTOCVYasbh2IqdM7ryyr
z3rL0l3LOySD73mv/YU4Dt1brScFXq4hA5IcXNGvyn1gUw3HD8/cbjGCAyYwggMiAgEBMFswVjEL
MAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMC
SFExFzAVBgNVBAMTDk9yaW9uIEVtYWlsIENBAgEhMAkGBSsOAwIaBQCgggGgMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyOTE4MDIzOVowIwYJKoZIhvcNAQkE
MRYEFIP7hE1+uGN3xmeHJSmlKrg/ir6JMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwBwYF
Kw4DAhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAoGCCqGSIb3DQIFMGoGCSsGAQQBgjcQBDFdMFswVjELMAkGA1UEBhMCVVMxITAfBgNVBAoT
GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVt
YWlsIENBAgEiMGwGCyqGSIb3DQEJEAILMV2gWzBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jp
b24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwg
Q0ECASIwDQYJKoZIhvcNAQEBBQAEggEAjbSQ8erqw5pS6KreOloSyfvzfo8dPS5+TvFy8Goou56A
E3oArVrgojQr8aLGt7cGr61XvZLS8JSgHirrd4DXdekoV3+kUU5VDC3fHA/4PSPMf7jr7vCtnl/L
PSHBX+e6jh+ax/paluhHmqnOqS8FkbEoPdiWxmr0uWnCq74riAIVqWYqsoJX2Uf1GTrdG+qPl2H3
2S5DsShnvVgdRpzrGnLga6eHrr8ihVeAUV9uOafF1GsRtShjw2Q0tjFxiWTiTk/vVpYWdNqMnhHw
KpCw4Oq3GQ70HmMoRUWfn5U7VE2OyRXlu/cgRCnfNAjkH2vGTQG+7/qgETalEWwntRHCNwAAAAAA
AA==

------=_NextPart_000_0060_01C39E1C.EE435990--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TGWlkT028217 for <[e-mail]>; Wed, 29 Oct 2003 08:32:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TGWlM6028216 for ietf-pkix-bks; Wed, 29 Oct 2003 08:32:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TGWjkT028210 for <[e-mail]>; Wed, 29 Oct 2003 08:32:46 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t11o913p45.telia.com [213.64.28.45]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id h9TGWMc4008383; Wed, 29 Oct 2003 17:32:23 +0100 (CET)
Message-ID: <00a801c39e39$cf4a1890$791a40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <001601c39e09$25d69520$4228a8c0@hagen> <01e801c39e1d$7c6cc850$651a40d5@arport> <p06002001bbc58537e2cb@[128.33.244.157]>
Subject: Re: Standards for Web-signing II
Date: Wed, 29 Oct 2003 17:29:20 +0100
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>since you obviously don't believe the IETF creates "real standards" 
>and since this topic is not a PKIX work item, I suggest you take the 
>"web-sigbing" discussion elsewhere.

As the off-list response to "web-signing" has been pretty good, I
just need to figure out where to go next.

You did probably not read more than the first paragraph.  To go
through a "real standardization process" was ONE of the stated
alternatives.

Anders


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TGNDkT027596 for <[e-mail]>; Wed, 29 Oct 2003 08:23:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TGNDev027595 for ietf-pkix-bks; Wed, 29 Oct 2003 08:23:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TGNBkT027589 for <[e-mail]>; Wed, 29 Oct 2003 08:23:11 -0800 (PST) (envelope-from [e-mail])
Received: from fwd08.aul.t-online.de  by mailout11.sul.t-online.com with smtp  id 1AEt6B-0007YA-01; Wed, 29 Oct 2003 17:23:07 +0100
Received: from hagen (VUfdcyZGoeXF5nFopPSwfEaUhvUSh3O-qgFSAPLA9qsKvuxM92bzZ2@[217.80.245.190]) by fmrl08.sul.t-online.com with esmtp id 1AEt68-0xHxnE0; Wed, 29 Oct 2003 17:23:04 +0100
From: "Florian Oelmaier" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'James Jing'" <[e-mail]>, "'Markus Lorch'" <[e-mail]>, <[e-mail]>
Subject: RE: Standards for Web-signing II
Date: Wed, 29 Oct 2003 17:23:03 +0100
Organization: SyTrust
Message-ID: <000101c39e38$ee9e6120$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <01e801c39e1d$7c6cc850$651a40d5@arport>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> However, Identrus is a bank-controlled operation and 
> therefore operate in the same way as banks regarding their 
> technology. I.e. by acting "possessive" and most of all being 
> scared that a competitor would ever be able to profit on the 
> work done.

We all know that acting "possessive" does not work really good on the
internet. After all a secrect shared by more than three people isnt a
secret anymore. If you need a hint at how the identrus Websigning works
you may look at
http://www.s-d.no/filer/manualer/Technical%20Description%203_1Rev1.pdf
and read the identrus section there.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TEwfkT022926 for <[e-mail]>; Wed, 29 Oct 2003 06:58:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TEwfpB022925 for ietf-pkix-bks; Wed, 29 Oct 2003 06:58:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TEwekT022918; Wed, 29 Oct 2003 06:58:40 -0800 (PST) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TEwOxA001116; Wed, 29 Oct 2003 06:58:24 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h9TEwNB19615; Wed, 29 Oct 2003 09:58:23 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2003 09:57:46 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Request change in son-of-rfc2633
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms58E8539260192E6D326EA0C4"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms58E8539260192E6D326EA0C4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anyone who "reads the PKIX tea leaves" and thinks that
it's fine to skip name chaining checks in path validation
needs to have their eyes checked. RFC 3280 says in many
places that name chaining MUST be checked.

In section 6.1:

 To meet this goal, the path validation process verifies, among other
 things, that a prospective certification path (a sequence of n
 certificates) satisfies the following conditions:

    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
    the issuer of certificate x+1;

In section 6.1.3:

 (a)  Verify the basic certificate information.  The certificate
 MUST satisfy each of the following:

 [...]

    (4)  The certificate issuer name is the working_issuer_name.

In section 4.1.2.6:

   If the subject is a CA (e.g., the basic constraints extension, as
   discussed in 4.2.1.10, is present and the value of cA is TRUE), then
   the subject field MUST be populated with a non-empty distinguished
   name matching the contents of the issuer field (section 4.1.2.4) in
   all certificates issued by the subject CA.

RFC 2459 and X.509 both agree with this.

Whatever PKI topology you use, there's no need to break
name chaining. I'm sure that some customers have created
PKIs where name chaining doesn't hold, but that's an error
on the customer's part. You can't just turn off critical
security checks to keep them happy. What's next? Don't
bother checking the signature on certificates. That takes
too much time!

If somebody has implemented path validation without name
chaining checks, then they haven't implemented it according
to IETF or X.509 standards. In fact, they may have opened
themselves and their customers up to security holes and
perhaps even legal liability. CAs have every right to expect
that certificates will be validated according to standards.
Users also have a reasonable expectation of this. If someone
deliberately violates the standards in a way that opens
up security holes, that sounds like gross negligence to me.

This reminds me of Microsoft's decision to not check the
Basic Constraints extension, treating every certificate
as a CA certificate. This decision, presumably made in
to please a customer, resulted in a HUGE security hole.

I hope that Microsoft (and anyone else who has skipped
required parts of the path validation algorithm for the
sake of convenience) will see that security cannot be
second to user convenience. If there's a serious problem
with the specs, then let's fix them. But don't just bypass
things because you find it convenient.

Forgive me my rant. I'm just outraged that somebody would
play fast and loose with security this way.

Thanks,

Steve

Peter Gutmann wrote:
> 
> [Cross-posted back to S/MIME, where the thread started]
> 
> Eric Norman <[e-mail]> writes:
> 
> >Is there a claim (#1 above) that you can have the DN in the subject of a
> >parent's (signer's) certificate be different from (as in different bunch of
> >bytes) the DN in the issuer of one of its offspring and yet the chain is
> >still valid because the xKIDs match?
> 
> Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI that
> violates the original X.509 design, i.e. with re-parenting, arbitrary cross-
> certification, etc etc where issuers no longer match subjects).  For example
> MS apparently implemented chaining by sKID in Windows because of user demand
> for this when the users broke chaining by issuer name through spaghetti PKI
> design practices, and various other implementations no doubt do similar
> things, depending on how they've read the PKIX tea leaves.
> 
> Peter.
--------------ms58E8539260192E6D326EA0C4
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMxMDI5MTQ1NzQ2WjAjBgkqhkiG9w0BCQQxFgQU4GYH3SPbd16nT9xTo5bjvv/V
bmMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBJKLwc
TwwpH14dBh0aE4gn3MRkvi2+fKiDitHUq5TeivEOYZK5rN0eXbxESLuxNnYl+Cp5zrdhvokV
8ThIbRyqfsorBhQ0P0GB7h72pEkfCxExzHBjtQsfqP6q5JMpup/zWWm3xHLbQlz9XtpGSwKo
xHrTgWBxWsHAMTWnOKeeSA==
--------------ms58E8539260192E6D326EA0C4--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TEv2kT022838 for <[e-mail]>; Wed, 29 Oct 2003 06:57:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TEv2pM022837 for ietf-pkix-bks; Wed, 29 Oct 2003 06:57:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TEv0kT022828 for <[e-mail]>; Wed, 29 Oct 2003 06:57:01 -0800 (PST) (envelope-from [e-mail])
Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h9TEutlq006741; Wed, 29 Oct 2003 09:56:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002001bbc58537e2cb@[128.33.244.157]>
In-Reply-To: <01e801c39e1d$7c6cc850$651a40d5@arport>
References: <001601c39e09$25d69520$4228a8c0@hagen> <01e801c39e1d$7c6cc850$651a40d5@arport>
Date: Wed, 29 Oct 2003 09:56:16 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Standards for Web-signing II
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 14:06 +0100 10/29/03, Anders Rundgren wrote:
>I believe this is a very good opportunity to study how
>"Real Standards" actually are made:
>

since you obviously don't believe the IETF creates "real standards" 
and since this topic is not a PKIX work item, I suggest you take the 
"web-sigbing" discussion elsewhere.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TEsjI7022729 for <[e-mail]>; Wed, 29 Oct 2003 06:54:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TEsjDb022728 for ietf-pkix-bks; Wed, 29 Oct 2003 06:54:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TEsgI7022720 for <[e-mail]>; Wed, 29 Oct 2003 06:54:43 -0800 (PST) (envelope-from [e-mail])
Received: (from root@localhost) by mystic1.trustcenter.de (8.11.6+Sun/8.11.6) id h9TEsRX13475; Wed, 29 Oct 2003 15:54:27 +0100 (MET)
Received: from venus.trustcenter.de(192.168.202.4) by mystic1.trustcenter.de via csmap (V6.0) id srcAAAtLaquA; Wed, 29 Oct 03 15:54:26 +0100
Received: from trustcenter.de (mv-hps.trustcenter.de [192.168.200.147]) by venus.trustcenter.de (8.12.9/TC TrustCenter Mailserver) with ESMTP id h9TEsOxh013797; Wed, 29 Oct 2003 15:54:25 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2003 15:53:29 +0100
From: Hans-Peter Schwebler <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Jing <[e-mail]>
CC: Anders Rundgren <[e-mail]>, [e-mail]
Subject: Re: Standards for Web-signing II
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James,

Identrus defined two methods for web signing (ISPI (Identrus Signing 
Plugin Interface ) and ISIL (Identrus Signing Interface Library)).
However, the latest version of the documentation allows for so called
standalone applications (e.g. Adobe Acrobat and Microsoft Office) to
use a "native" signature mechanism which, of course, needs to satisfy
a couple of requirements set be Identrus.

I just want to point this out. I don't want to comment on it because
I am not yet sure whether I like this move or not.

And Anders, yes of course, Identrus is such an organization that 
provides technical documents under NDA only. Unless they have
changed their policy on that in the last weeks.

Regards,
Hans-Peter 

James Jing wrote:
> 
> Identrus, a global banking PKI body, defined two methods for web 
> signing. One is defined as a Netscape style browser plug-in, the 
> other defined as an abstract Java interface. It also requires the 
> content that is being signed to be separately displayed, and the 
> digest of the content to be calculated by the "trusted subsystem".
> 
> I personally think the best approach would be for a unified standard 
> to be adopted by all browsers, invocable by all common scripts like 
> JavaScript, regardless of what the underlying implementation of the 
> signature layer might be. I believe both PKCS#7 and XML standards 
> must be supported. Content-to-be-signed should be defined by MIME-type 
> so if the browser needs to popup another screen, it can be properly 
> display the content. Whether a separate popup should be displayed must 
> be determined by signature layer based on the type of key being used 
> to sign the content.
> 
> Regards
> James


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TD9fI7017782 for <[e-mail]>; Wed, 29 Oct 2003 05:09:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TD9foj017781 for ietf-pkix-bks; Wed, 29 Oct 2003 05:09:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TD9dI7017776 for <[e-mail]>; Wed, 29 Oct 2003 05:09:40 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t10o913p89.telia.com [213.64.27.209]) by smtp1.fre.skanova.net (8.12.10/8.12.10) with SMTP id h9TD9bO2017768; Wed, 29 Oct 2003 14:09:37 +0100 (CET)
Message-ID: <01e801c39e1d$7c6cc850$651a40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "'James Jing'" <[e-mail]>, "'Markus Lorch'" <[e-mail]>, <[e-mail]>
References: <001601c39e09$25d69520$4228a8c0@hagen>
Subject: Re: Standards for Web-signing II
Date: Wed, 29 Oct 2003 14:06:35 +0100
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I believe this is a very good opportunity to study how
"Real Standards" actually are made:

If a vendor has a nice browser add-in solution that it believes
is worth the title "standard", there are a number of ways to
pursue this such as:

- Submitting the solution as "input" to a standards process.
  Costly, time-consuming, and potentially dangerous as you
  have to give up the control (well, maybe not if you are a
  BIG enough vendor...)

- Make the code available for free download in order to
  spread the solution, and blocking competing efforts.
  A vey popular method indeed!

- Submitting the code to let's say Microsoft, Mozilla.org etc
  for free inclusion, and by that establishing a "de-facto" standard

However, Identrus is a bank-controlled operation and therefore
operate in the same way as banks regarding their technology.
I.e. by acting "possessive" and most of all being scared that
a competitor would ever be able to profit on the work done.

A similar thing is the EMV-card that surely could replace most
other PKI cards on the market, but since it is also owned by a
bank-controlled entity, they will probably never make the client
software downloadable, a preinstall in Windows, or make the
card purchasable in small quantities on the web by anybody, and
will therefore most likely fail to establish EMV as a "de-facto"
standard.

If bank executives ever go to the Cinema(?), or rent a video,
they should take a look on the movie "A beautiful mind"
while at the same time thinking on the establishment of
important e-infrastructures.  Unfortunately, when you get
a fresh view on things, you often fail to apply it to your
own backyard because that "is a different thing".  But
it isn't, the problems with establishing common e-standards
are pretty universal and so are the "workarounds".  Unless
you are Microsoft and actually can do whatever you want,
and most of the time it even get it to work fairly well.

Anders Rundgren


----- Original Message -----
From: "Florian Oelmaier" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>; "'James Jing'" <[e-mail]>; "'Markus Lorch'" <[e-mail]>;
<[e-mail]>
Sent: Wednesday, October 29, 2003 11:41
Subject: RE: Standards for Web-signing II


> >Identrus, a global banking PKI body, defined two methods for web
> >signing. One is defined as a Netscape style browser plug-in,
> the other
> >defined as an abstract Java interface.
>
> The Netscape plugin interface was dropped in IE V6 and Java
> does not look like an MSFT favorite.  This was just a side note.

Identrus defined a MIME-type to be used within an <EMBED>- or an
<OBJECT>-tag to include the signing plugin into HTML-pages. What type of
plugin processes this tag is not of concern to the identrus
specification. Netscape plugins or IE native plugins: both plugin
architectures should be able to handle the defined tag.

--
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TAfQI7008169 for <[e-mail]>; Wed, 29 Oct 2003 02:41:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TAfQJ0008167 for ietf-pkix-bks; Wed, 29 Oct 2003 02:41:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TAfMI7008152 for <[e-mail]>; Wed, 29 Oct 2003 02:41:22 -0800 (PST) (envelope-from [e-mail])
Received: from fwd09.aul.t-online.de  by mailout03.sul.t-online.com with smtp  id 1AEnlL-0002lL-0I; Wed, 29 Oct 2003 11:41:15 +0100
Received: from hagen (JON6EeZEwe70HluZ323FFPROaEi9O7ckcEE5VgwBQuJOTUmh0XuNga@[80.128.88.21]) by fmrl09.sul.t-online.com with esmtp id 1AEnl9-2KtOkq0; Wed, 29 Oct 2003 11:41:03 +0100
From: "Florian Oelmaier" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'James Jing'" <[e-mail]>, "'Markus Lorch'" <[e-mail]>, <[e-mail]>
Subject: RE: Standards for Web-signing II
Date: Wed, 29 Oct 2003 11:41:01 +0100
Organization: SyTrust
Message-ID: <001601c39e09$25d69520$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <009701c39de7$35823dc0$651a40d5@arport>
Importance: Normal
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >Identrus, a global banking PKI body, defined two methods for web 
> >signing. One is defined as a Netscape style browser plug-in, 
> the other 
> >defined as an abstract Java interface.
> 
> The Netscape plugin interface was dropped in IE V6 and Java 
> does not look like an MSFT favorite.  This was just a side note.

Identrus defined a MIME-type to be used within an <EMBED>- or an
<OBJECT>-tag to include the signing plugin into HTML-pages. What type of
plugin processes this tag is not of concern to the identrus
specification. Netscape plugins or IE native plugins: both plugin
architectures should be able to handle the defined tag.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T6fCI7043669 for <[e-mail]>; Tue, 28 Oct 2003 22:41:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T6fCiT043668 for ietf-pkix-bks; Tue, 28 Oct 2003 22:41:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T6f8I7043594 for <[e-mail]>; Tue, 28 Oct 2003 22:41:09 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t7o913p101.telia.com [213.64.26.101]) by smtp1.fre.skanova.net (8.12.10/8.12.10) with SMTP id h9T6ehO2008646; Wed, 29 Oct 2003 07:40:44 +0100 (CET)
Message-ID: <009701c39de7$35823dc0$651a40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: "James Jing" <[e-mail]>, "Markus Lorch" <[e-mail]>, <[e-mail]>, "Florian Oelmaier" <[e-mail]>
References: <[e-mail]>
Subject: Re: Standards for Web-signing II
Date: Wed, 29 Oct 2003 07:37:40 +0100
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Identrus, a global banking PKI body, defined two methods for
>web signing. One is defined as a Netscape style
>browser plug-in, the other defined as an abstract Java interface. 

The Netscape plugin interface was dropped in IE V6 and Java
does not look like an MSFT favorite.  This was just a side note.

>It also requires the content that is being signed to be
>separately displayed, and the digest of the content to be
>calculated by the "trusted subsystem".

Identrus, is I guess one of these parties requiring NDA?

>I personally think the best approach would be for a unified standard to
>be adopted by all browsers, invocable by all common scripts like
>JavaScript, regardless of what the underlying implementation of the
>signature layer might be. 
>I believe both PKCS#7 and XML standards
>must be supported. Content-to-be-signed should be defined by
>MIME-type so if the browser needs to popup another screen, it
>can be properly display the content. Whether a separate popup
>should be displayed must be determined by signature layer based
>on the type of key being used to sign the content.

I agree!
Although I do believe on-line signing is still a field that needs a
little more research as it is really very different to off-line.

Anders

Regards
James


-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Wednesday, 29 October 2003 6:59 AM
To: Markus Lorch; [e-mail]
Subject: Re: Standards for Web-signing II



Markus,

XML Signature standard essentially define something like
CMS/PKCS #7 in XML.  The standard "talks" about the signing
process but does not define any interface between the browser
and the signature requester which is what is needed among
many things in order to achieve a web-signing standard.

But this one is just for starters, the browser-interface for
on-line certfication processes (which seem to be the future)
is also not standardized.  MSFT's Xenroll has no implementation
in Mozilla or Netscape.  Few serious systems for this reason
build on Xenroll but rather on proprietary solutions.  Xenroll
is also in my opinion an unsatisfactory solution as the GUI
should be the same for each CA rather than all over the map.

rgds
Anders

----- Original Message ----- 
From: "Markus Lorch" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>; <[e-mail]>
Sent: Tuesday, October 28, 2003 20:01
Subject: RE: Standards for Web-signing II


Anders,

isn't the XML Signature a standard that can be used for this

see
Mark Bartel et al, "XML Signature Syntax and Processing", World Wide Web
Consortium Recommendation, February 2002

Markus

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Standards for Web-signing II
> 
> 
> 
> The answer to my earlier request seems to be:
> 
> There are apparently no standards and nothing in the works either
> with respect to signing on-line data on the web using 
> Internet browsers.
> 
> Since web-signing is today [*] used by many, many, more people
> and organizations than there are users of signed e-email, I 
> remain puzzled.
> 
> Is the PKI community really just a bunch of "nerds", mostly
> out of touch with the needs of the market?  The question is open.
> 
> *] Like Scandinavian banks having > 0.5M of users.
> All current systems rely on entirely proprietary mechanisms.
> Most of the vendors even require NDAs for getting the documentation.
> 
> Anders Rundgren
> 
> 
> ----- Original Message -----
> From: "Anders Rundgren" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; 
> <[e-mail]>
> Sent: Tuesday, September 02, 2003 14:07
> Subject: [pki-tc] Standards for Web-signing
> 
> 
> Folks,
> I just wanted to know the status of possible standardization
> efforts regarding signing on-line forms etc. on web.  As web-signing
> is a core function of many e-governments when communicating
> with their citizens it seems that this should be standardized if
> not already is.
> 
> Pointers are welcome.  Off-list or on-list.
> 
> rgds
> Anders Rundgren
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/le
ave_workgroup.php.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3ZhI7021502 for <[e-mail]>; Tue, 28 Oct 2003 19:35:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T3ZhHg021501 for ietf-pkix-bks; Tue, 28 Oct 2003 19:35:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3ZfI7021494; Tue, 28 Oct 2003 19:35:42 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T3Zfo9008396; Wed, 29 Oct 2003 16:35:41 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T3bu208738; Wed, 29 Oct 2003 16:37:56 +1300
Date: Wed, 29 Oct 2003 16:37:56 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Request change in son-of-rfc2633
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Cross-posted back to S/MIME, where the thread started]

Eric Norman <[e-mail]> writes:

>Is there a claim (#1 above) that you can have the DN in the subject of a
>parent's (signer's) certificate be different from (as in different bunch of
>bytes) the DN in the issuer of one of its offspring and yet the chain is
>still valid because the xKIDs match?

Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI that
violates the original X.509 design, i.e. with re-parenting, arbitrary cross-
certification, etc etc where issuers no longer match subjects).  For example
MS apparently implemented chaining by sKID in Windows because of user demand
for this when the users broke chaining by issuer name through spaghetti PKI
design practices, and various other implementations no doubt do similar
things, depending on how they've read the PKIX tea leaves.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T0bBI7014329 for <[e-mail]>; Tue, 28 Oct 2003 16:37:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T0bBvH014328 for ietf-pkix-bks; Tue, 28 Oct 2003 16:37:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T0b9I7014323 for <[e-mail]>; Tue, 28 Oct 2003 16:37:10 -0800 (PST) (envelope-from [e-mail])
Received: from fwd09.aul.t-online.de  by mailout09.sul.t-online.com with smtp  id 1AEeKl-00080C-00; Wed, 29 Oct 2003 01:37:11 +0100
Received: from hagen (STC2kyZOreXEk1n2ub+BZnZQjBbTpEj91VD9J1ISav7mTuYA7vIF8E@[80.128.82.93]) by fmrl09.sul.t-online.com with esmtp id 1AEeKe-0Mc8NU0; Wed, 29 Oct 2003 01:37:04 +0100
From: "Florian Oelmaier" <[e-mail]>
To: "'Markus Lorch'" <[e-mail]>, "'Anders Rundgren'" <[e-mail]>, <[e-mail]>
Subject: RE: Standards for Web-signing II
Date: Wed, 29 Oct 2003 01:37:05 +0100
Organization: SyTrust
Message-ID: <00ee01c39db4$c7396f50$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <017201c39d85$dc447130$6e00a8c0@voyager>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Folks,
> > I just wanted to know the status of possible 
> standardization efforts 
> > regarding signing on-line forms etc. on web.  As 
> web-signing is a core 
> > function of many e-governments when communicating with 
> their citizens 
> > it seems that this should be standardized if not already is.
> > 
> > Pointers are welcome.  Off-list or on-list.

Most products out there are more or less compliant with the identrus
specifications for websigning (ISIL & ISPI). These specifications are
not openly available but from a technical point of view these specs are
not limited to identrus usage.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SN47I7010688 for <[e-mail]>; Tue, 28 Oct 2003 15:04:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SN471n010687 for ietf-pkix-bks; Tue, 28 Oct 2003 15:04:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from figg.securenet.com.au (ns2.isecure.com.au [202.125.4.72]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SN42I7010675 for <[e-mail]>; Tue, 28 Oct 2003 15:04:05 -0800 (PST) (envelope-from [e-mail])
Received: from iron.securenet.com.au (iron.isecure.com.au [202.125.4.94] (may be forged)) by figg.securenet.com.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9SN3ood015939; Wed, 29 Oct 2003 10:03:50 +1100
Received: (from uucp@localhost) by iron.securenet.com.au (8.12.6/8.12.6) id h9SN3ovH025658; Wed, 29 Oct 2003 10:03:50 +1100 (EST)
Received: from nodnsquery(10.11.3.10) by iron.securenet.com.au via csmap (V6.0) id srcAAAw0aihY; Wed, 29 Oct 03 10:03:50 +1100
Received: from atlas.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian-7woody) with ESMTP id h9SN3nHT007369; Wed, 29 Oct 2003 10:03:49 +1100
Received: from AMALTHEA.securenet.com.au ([192.168.100.30]) by atlas.securenet.com.au with Microsoft SMTPSVC(5.0.2195.4905); Wed, 29 Oct 2003 10:03:32 +1100
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Standards for Web-signing II
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 29 Oct 2003 10:02:20 +1100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Standards for Web-signing II
Thread-Index: AcOdoQUovlAiDSCVQYitPD4AmH6OXQABNLoQ
From: "James Jing" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, "Markus Lorch" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 28 Oct 2003 23:03:32.0421 (UTC) FILETIME=[B55A7750:01C39DA7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9SN45I7010683
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Identrus, a global banking PKI body, defined two methods for web signing. One is defined as a Netscape style browser plug-in, the other defined as an abstract Java interface. It also requires the content that is being signed to be separately displayed, and the digest of the content to be calculated by the "trusted subsystem".

I personally think the best approach would be for a unified standard to be adopted by all browsers, invocable by all common scripts like JavaScript, regardless of what the underlying implementation of the signature layer might be. I believe both PKCS#7 and XML standards must be supported. Content-to-be-signed should be defined by MIME-type so if the browser needs to popup another screen, it can be properly display the content. Whether a separate popup should be displayed must be determined by signature layer based on the type of key being used to sign the content.

Regards
James


-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Wednesday, 29 October 2003 6:59 AM
To: Markus Lorch; [e-mail]
Subject: Re: Standards for Web-signing II



Markus,

XML Signature standard essentially define something like
CMS/PKCS #7 in XML.  The standard "talks" about the signing
process but does not define any interface between the browser
and the signature requester which is what is needed among
many things in order to achieve a web-signing standard.

But this one is just for starters, the browser-interface for
on-line certfication processes (which seem to be the future)
is also not standardized.  MSFT's Xenroll has no implementation
in Mozilla or Netscape.  Few serious systems for this reason
build on Xenroll but rather on proprietary solutions.  Xenroll
is also in my opinion an unsatisfactory solution as the GUI
should be the same for each CA rather than all over the map.

rgds
Anders

----- Original Message ----- 
From: "Markus Lorch" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>; <[e-mail]>
Sent: Tuesday, October 28, 2003 20:01
Subject: RE: Standards for Web-signing II


Anders,

isn't the XML Signature a standard that can be used for this

see
Mark Bartel et al, "XML Signature Syntax and Processing", World Wide Web
Consortium Recommendation, February 2002

Markus

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Standards for Web-signing II
> 
> 
> 
> The answer to my earlier request seems to be:
> 
> There are apparently no standards and nothing in the works either
> with respect to signing on-line data on the web using 
> Internet browsers.
> 
> Since web-signing is today [*] used by many, many, more people
> and organizations than there are users of signed e-email, I 
> remain puzzled.
> 
> Is the PKI community really just a bunch of "nerds", mostly
> out of touch with the needs of the market?  The question is open.
> 
> *] Like Scandinavian banks having > 0.5M of users.
> All current systems rely on entirely proprietary mechanisms.
> Most of the vendors even require NDAs for getting the documentation.
> 
> Anders Rundgren
> 
> 
> ----- Original Message -----
> From: "Anders Rundgren" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; 
> <[e-mail]>
> Sent: Tuesday, September 02, 2003 14:07
> Subject: [pki-tc] Standards for Web-signing
> 
> 
> Folks,
> I just wanted to know the status of possible standardization
> efforts regarding signing on-line forms etc. on web.  As web-signing
> is a core function of many e-governments when communicating
> with their citizens it seems that this should be standardized if
> not already is.
> 
> Pointers are welcome.  Off-list or on-list.
> 
> rgds
> Anders Rundgren
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/le
ave_workgroup.php.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKiaI7004092 for <[e-mail]>; Tue, 28 Oct 2003 12:44:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SKiaFP004091 for ietf-pkix-bks; Tue, 28 Oct 2003 12:44:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SKiWI7004086 for <[e-mail]>; Tue, 28 Oct 2003 12:44:32 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25364; Tue, 28 Oct 2003 15:44:22 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-02.txt
Date: Tue, 28 Oct 2003 15:44:22 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure:Qualified Certificates Profile
	Author(s)	: S. Santesson, M. Nystrom
	Filename	: draft-ietf-pkix-sonof3039-02.txt
	Pages		: 35
	Date		: 2003-10-28
	
This document forms a certificate profile, based on RFC 3280, for
dentity certificates issued to physical persons.
The goal of this document is to define a general syntax independent
of local legal requirements.  The profile is however designed to
allow further profiling in order to meet specific local needs.
The profile defines specific conventions for certificates that are
qualified within a defined legal framework, named Qualified
Certificates. The profile does however not define any legal
requirements for such Qualified Certificates.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-sonof3039-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-sonof3039-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-sonof3039-02.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SK22I7002189 for <[e-mail]>; Tue, 28 Oct 2003 12:02:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SK22YG002188 for ietf-pkix-bks; Tue, 28 Oct 2003 12:02:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SK21I7002182 for <[e-mail]>; Tue, 28 Oct 2003 12:02:02 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t7o913p99.telia.com [213.64.26.99]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id h9SK21o5001185; Tue, 28 Oct 2003 21:02:01 +0100 (CET)
Message-ID: <003b01c39d8d$edcadb30$721a40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Markus Lorch" <[e-mail]>, <[e-mail]>
References: <017201c39d85$dc447130$6e00a8c0@voyager>
Subject: Re: Standards for Web-signing II
Date: Tue, 28 Oct 2003 20:58:59 +0100
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Markus,

XML Signature standard essentially define something like
CMS/PKCS #7 in XML.  The standard "talks" about the signing
process but does not define any interface between the browser
and the signature requester which is what is needed among
many things in order to achieve a web-signing standard.

But this one is just for starters, the browser-interface for
on-line certfication processes (which seem to be the future)
is also not standardized.  MSFT's Xenroll has no implementation
in Mozilla or Netscape.  Few serious systems for this reason
build on Xenroll but rather on proprietary solutions.  Xenroll
is also in my opinion an unsatisfactory solution as the GUI
should be the same for each CA rather than all over the map.

rgds
Anders

----- Original Message ----- 
From: "Markus Lorch" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>; <[e-mail]>
Sent: Tuesday, October 28, 2003 20:01
Subject: RE: Standards for Web-signing II


Anders,

isn't the XML Signature a standard that can be used for this

see
Mark Bartel et al, "XML Signature Syntax and Processing", World Wide Web
Consortium Recommendation, February 2002

Markus

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Standards for Web-signing II
> 
> 
> 
> The answer to my earlier request seems to be:
> 
> There are apparently no standards and nothing in the works either
> with respect to signing on-line data on the web using 
> Internet browsers.
> 
> Since web-signing is today [*] used by many, many, more people
> and organizations than there are users of signed e-email, I 
> remain puzzled.
> 
> Is the PKI community really just a bunch of "nerds", mostly
> out of touch with the needs of the market?  The question is open.
> 
> *] Like Scandinavian banks having > 0.5M of users.
> All current systems rely on entirely proprietary mechanisms.
> Most of the vendors even require NDAs for getting the documentation.
> 
> Anders Rundgren
> 
> 
> ----- Original Message -----
> From: "Anders Rundgren" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; 
> <[e-mail]>
> Sent: Tuesday, September 02, 2003 14:07
> Subject: [pki-tc] Standards for Web-signing
> 
> 
> Folks,
> I just wanted to know the status of possible standardization
> efforts regarding signing on-line forms etc. on web.  As web-signing
> is a core function of many e-governments when communicating
> with their citizens it seems that this should be standardized if
> not already is.
> 
> Pointers are welcome.  Off-list or on-list.
> 
> rgds
> Anders Rundgren
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/le
ave_workgroup.php.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SJ1II7099585 for <[e-mail]>; Tue, 28 Oct 2003 11:01:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SJ1Iw5099583 for ietf-pkix-bks; Tue, 28 Oct 2003 11:01:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SJ1GI7099578 for <[e-mail]>; Tue, 28 Oct 2003 11:01:17 -0800 (PST) (envelope-from [e-mail])
Received: from vivi.cc.vt.edu (IDENT:mirapoint@evil-vivi [10.1.1.12]) by lennier.cc.vt.edu (8.12.8/8.12.8) with ESMTP id h9SJ1IxY226186; Tue, 28 Oct 2003 14:01:18 -0500 (EST)
Received: from voyager (zuni.cs.vt.edu [128.173.54.49]) by vivi.cc.vt.edu (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id BWO52500; Tue, 28 Oct 2003 14:01:16 -0500 (EST)
From: "Markus Lorch" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, <[e-mail]>
Subject: RE: Standards for Web-signing II
Date: Tue, 28 Oct 2003 14:01:14 -0500
Message-ID: <017201c39d85$dc447130$6e00a8c0@voyager>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-reply-to: <00e401c39d59$ed8396a0$381b40d5@arport>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

isn't the XML Signature a standard that can be used for this

see
Mark Bartel et al, "XML Signature Syntax and Processing", World Wide Web
Consortium Recommendation, February 2002

Markus

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Standards for Web-signing II
> 
> 
> 
> The answer to my earlier request seems to be:
> 
> There are apparently no standards and nothing in the works either
> with respect to signing on-line data on the web using 
> Internet browsers.
> 
> Since web-signing is today [*] used by many, many, more people
> and organizations than there are users of signed e-email, I 
> remain puzzled.
> 
> Is the PKI community really just a bunch of "nerds", mostly
> out of touch with the needs of the market?  The question is open.
> 
> *] Like Scandinavian banks having > 0.5M of users.
> All current systems rely on entirely proprietary mechanisms.
> Most of the vendors even require NDAs for getting the documentation.
> 
> Anders Rundgren
> 
> 
> ----- Original Message -----
> From: "Anders Rundgren" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; 
> <[e-mail]>
> Sent: Tuesday, September 02, 2003 14:07
> Subject: [pki-tc] Standards for Web-signing
> 
> 
> Folks,
> I just wanted to know the status of possible standardization
> efforts regarding signing on-line forms etc. on web.  As web-signing
> is a core function of many e-governments when communicating
> with their citizens it seems that this should be standardized if
> not already is.
> 
> Pointers are welcome.  Off-list or on-list.
> 
> rgds
> Anders Rundgren
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/le
ave_workgroup.php.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SHi6I7096608 for <[e-mail]>; Tue, 28 Oct 2003 09:44:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SHi6S9096607 for ietf-pkix-bks; Tue, 28 Oct 2003 09:44:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SHi4I7096602 for <[e-mail]>; Tue, 28 Oct 2003 09:44:05 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA08263; Tue, 28 Oct 2003 18:44:03 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 28 Oct 2003 18:44:03 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id h9SHhw419224; Tue, 28 Oct 2003 18:43:58 +0100 (MET)
Date: Tue, 28 Oct 2003 18:43:58 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: SCVP additions
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hello,

It would be nice to hear whether all or which comments
about SCVP have been addressed. Unless I have overlooked
something, my remarks about the definitions of requestor
and responder have not received any treatment. 

I simplify the content of my comments:

requestor and responder should be GENERALNAMES which
indicate and identify in global the partipating parties.  

IMO Using arbitrary octets with only LOCAL significance
is not compatible with the procedure to detect loops.

4.6 indicates the there MUST NOt be null characters,
something which is explicitly allowed for a server
acting as a relay.

What is the sense of 4.7? The responder field is
never used anywhere in the actual protocol, what
is the meaning of such an opaque value?


4.8.5 What is the reason of having an additional octet string
encapsulation instead of an any defined by construct? Is it
that some tools may break decodeing when they find an OID
that is not known? If so, whay are there ANY DEFINED BYs at
other places?

can someone indicate me how a relay would return the response
of the next server to a client as part of his response?

regards





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEVCI7084074 for <[e-mail]>; Tue, 28 Oct 2003 06:31:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SEVCVk084073 for ietf-pkix-bks; Tue, 28 Oct 2003 06:31:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEV7I7084064 for <[e-mail]>; Tue, 28 Oct 2003 06:31:07 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23475; Tue, 28 Oct 2003 09:30:56 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-13.txt
Date: Tue, 28 Oct 2003 09:30:56 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-13.txt
	Pages		: 49
	Date		: 2003-10-27
	
SCVP allows a client to offload certificate handling to a server.  
The server can provide the client with a variety of valuable 
information about the certificate, such as whether the certificate 
is valid, a certification path to a trust anchor, and revocation 
status.  SCVP has many purposes, including simplifying client 
implementations and allowing companies to centralize trust and 
policy management.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-13.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-13.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-13.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEV1I7084057 for <[e-mail]>; Tue, 28 Oct 2003 06:31:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SEV1dI084056 for ietf-pkix-bks; Tue, 28 Oct 2003 06:31:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEUxI7084047 for <[e-mail]>; Tue, 28 Oct 2003 06:31:00 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23458; Tue, 28 Oct 2003 09:30:50 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sim-01.txt
Date: Tue, 28 Oct 2003 09:30:49 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
	Author(s)	: J. Park
	Filename	: draft-ietf-pkix-sim-01.txt
	Pages		: 12
	Date		: 2003-10-27
	
This document provides the new straightforward approach to generate 
and verify unique information for identifying of the certificate 
subject. 
A Virtual ID(VID) may be put into the 'othername' field of the X.509 
subjectAltName certificate extension to make provisions for 
identifying the subject.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-sim-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-sim-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SDntI7081342 for <[e-mail]>; Tue, 28 Oct 2003 05:49:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SDntMw081341 for ietf-pkix-bks; Tue, 28 Oct 2003 05:49:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SDnqI7081325; Tue, 28 Oct 2003 05:49:53 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t8o913p105.telia.com [213.64.26.225]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id h9SDndo5010131; Tue, 28 Oct 2003 14:49:40 +0100 (CET)
Message-ID: <00e401c39d59$ed8396a0$381b40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <001501c37153$4ff1d960$0500a8c0@arport>
Subject: Standards for Web-signing II
Date: Tue, 28 Oct 2003 14:46:37 +0100
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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The answer to my earlier request seems to be:

There are apparently no standards and nothing in the works either
with respect to signing on-line data on the web using Internet browsers.

Since web-signing is today [*] used by many, many, more people
and organizations than there are users of signed e-email, I remain puzzled.

Is the PKI community really just a bunch of "nerds", mostly
out of touch with the needs of the market?  The question is open.

*] Like Scandinavian banks having > 0.5M of users.
All current systems rely on entirely proprietary mechanisms.
Most of the vendors even require NDAs for getting the documentation.

Anders Rundgren


----- Original Message -----
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Tuesday, September 02, 2003 14:07
Subject: [pki-tc] Standards for Web-signing


Folks,
I just wanted to know the status of possible standardization
efforts regarding signing on-line forms etc. on web.  As web-signing
is a core function of many e-governments when communicating
with their citizens it seems that this should be standardized if
not already is.

Pointers are welcome.  Off-list or on-list.

rgds
Anders Rundgren

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/leave_workgroup.php.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SCObI7077250 for <[e-mail]>; Tue, 28 Oct 2003 04:24:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SCOax3077249 for ietf-pkix-bks; Tue, 28 Oct 2003 04:24:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SCOYI7077228 for <[e-mail]>; Tue, 28 Oct 2003 04:24:34 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 12:24:28 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 Oct 2003 12:24:28 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Oct 2003 12:24:27 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: Finalizing sonOfRFC3039
Date: Tue, 28 Oct 2003 12:23:10 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Finalizing sonOfRFC3039
Thread-Index: AcOdTj//uIo8VUwURhOp4GIujLpe0g==
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Cc: "Tim Polk" <[e-mail]>, "Nystrom, Magnus" <[e-mail]>
X-OriginalArrivalTime: 28 Oct 2003 12:24:27.0873 (UTC) FILETIME=[6E38C510:01C39D4E]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C39D4E.6E308D7D"

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

All,

=20

It is time to close the son of RFC 3039 work item and move on.

A new draft was submitted before the cut-off 09.00 yesterday and will
hopefully appear on the IETF PKIX web soon.

=20

In this mail I will summarize the edits that has been done to this
document since RFC 3039.

It is my hope that any issues that anyone may have with this update can
be resolved during IETF in Minneapolis by either direct discussions or
e-mail.

=20

/Stefan

=20

Background:

=20

RFC 3039 is widely adopted and referenced throughout Europe as RFC 3039
together with the ETSI standard TS 101 862 is the common profile for
issuing Qualified Certificates (QC).

TS 101862 defines how to comply with the European electronic signature
directive and RFC 3039 forms the base profile on which TS 101862 is
based.

RFC 3039, however is widely used also for non-QC where TS 101862 doesn't
apply.

=20

This year ETSI initiated a work item (STF 220 Task 3) to further
harmonize public certificates issued to physical persons in Europe. The
deliverables are to:

-          Contribute to the update of RFC 3039

-          Update TS 101862

-          Generate new Technical Specification (TS 102 280) based on
the updated standards above.

=20

The new standard TS 102280 is intended as a generic ID-certificate
profile recognized throughout EU CA:s and service providers.

A first draft of TS 102280 has been produced and can be obtained by me
upon request.

=20

Updates to RFC 3039

=20

As stated above, it is important to finalize son of RFC 3039 in order to
finalize TS 102280 within its time frame (publication in April 04)

STF 220 Task 3 has produced, as part of its work, input to the update of
RFC 3039 (included below) that has been circulated among CA:s and
application providers mainly in Europe.

=20

Summary of updates are:

-          Various editorial updates of document scope and introductory
sections

-          Reference updates (e.g. changed RFC 2459 to RFC 3280)

-          domainComponent attribute added to subject field attribute
list

-          title attribute added to subject field attribute list

-          postalAddress removed from subject field attribute list

-          title removed from subjectDirectoryAttribute extension
attribute list

-          Key usage: Recommendation that NR SHOULD be exclusive if set
has been removed

-          Scope update of qcStatements extension

=20

It is important to note that NO syntax changes has been made to the
document.

=20

Further actions before producing RFC:

- finalize reference updates (X.509 is still old reference)

- Finalize ASN.1 parts (get new assigned numbers)

=20

=20

Recommendations from ETSI STF 220 Task 3

=20

Following is the section 2 from the STF 220 Task 3 requirements
document. The whole document can be obtained from me upon request.

=20

2   Recommendations on RFC 3039 updates=20

As part of this task, STF will seek to influence the update of RFC 3039
to adapt the following changes:

=20

2.1 Scope

RFC 3039 defines a number of aspects that are generic for both Qualified
Certificates as well as certificates to physical persons that are not
"Qualified". Examples are defined attributes, biometricInfo extension,
and aspects of the qcStatements extension. The scope of RFC 3039 should
be updated to more clearly reflect this reality, as well as other
proposed changes to the profile.

=20

2.2 References

References need to be updated. E.g. from RFC 2459 to RFC 3280

=20

2.3 Key usage

As a result of generalizing RFC 3039, the current requirement of having
non-repudiation exclusive if set, becomes too specific and cause
confusion in term of for which cases this applies and which cases it
does not. This has shown to diminish the use of other functions of RFC
3039 in certificates where RFC 3039 in general applies, but this
paragraph does not.

=20

=20

2.4 Subject field

The set of attributes should be updated.

=20

postalAddress should be removed from the list of attributes in the
subject field and title attribute should be included and removed from
the subjectDirectoryAttributes extension.

=20

PostalAddress is not supported by RFC 3280 for use in the subject field
and no records of its use in the subject field in public certificates,
as a distinguishing attribute, has been encountered. It is also a
structured attribute and therefore not appropriate for use as an RDN.=20

=20

Title on the other hand is frequently used. The common place to put this
attribute is in the subject field. Since we recommend against use of the
subjectDirectoryAttribute extension, the recommended location of the
title attribute should be in the subject field.

=20

domainComponent attribute should be added to the list of distingushing
subject attributes. This attribute is commonly used in Subject field,
primary as alternative to Country and Organization.

=20

2.5 qcStatements extension

The defined scope of this extension should be considered for update and
adaptation to its current and potential use.

=20

The important thing is thus to preserve the syntax of the qcStatements
extension in order to secure backwards compatibility.=20

=20


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

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:337537144;
	mso-list-type:hybrid;
	mso-list-template-ids:1206391600 -2061464258 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";}
@list l1
	{mso-list-id:887566121;
	mso-list-type:hybrid;
	mso-list-template-ids:597996132 -2061464258 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>All,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>It is time to close the son of RFC 3039 work item and =
move
on.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>A new draft was submitted before the cut-off 09.00 =
yesterday
and will hopefully appear on the IETF PKIX web =
soon.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In this mail I will summarize the edits that has been =
done
to this document since RFC 3039.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>It is my hope that any issues that anyone may have =
with this
update can be resolved during IETF in <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Minneapolis</st1:place></st1:City>
by either direct discussions or e-mail.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>/Stefan<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><u><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Background:<o:p></o:p></span></font><=
/u></b></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>RFC 3039 is widely adopted and referenced throughout =
Europe
as RFC 3039 together with the ETSI standard TS 101&nbsp;862 is the =
common profile
for issuing Qualified Certificates (QC).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>TS 101862 defines how to comply with the European =
electronic
signature directive and RFC 3039 forms the base profile on which TS =
101862 is
based.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>RFC 3039, however is widely used also for non-QC =
where TS
101862 doesn&#8217;t apply.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This year ETSI initiated a work item (STF 220 Task 3) =
to
further harmonize public certificates issued to physical persons in =
<st1:place
w:st=3D"on">Europe</st1:place>. The deliverables are =
to:<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Contribute to the update of =
RFC 3039<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Update TS =
101862<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Generate new Technical =
Specification
(TS 102&nbsp;280) based on the updated standards =
above.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The new standard TS 102280 is intended as a generic
ID-certificate profile recognized throughout <st1:place =
w:st=3D"on"><st1:City
 w:st=3D"on">EU</st1:City> <st1:State =
w:st=3D"on">CA</st1:State></st1:place>:s and
service providers.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>A first draft of TS 102280 has been produced and can =
be
obtained by me upon request.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><b><u><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Updates to RFC =
3039<o:p></o:p></span></font></u></b></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>As stated above, it is important to finalize son of =
RFC 3039
in order to finalize TS 102280 within its time frame (publication in =
April 04)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>STF 220 Task 3 has produced, as part of its work, =
input to
the update of RFC 3039 (included below) that has been circulated among =
CA:s and
application providers mainly in <st1:place =
w:st=3D"on">Europe</st1:place>.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Summary of updates are:<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Various editorial updates =
of document
scope and introductory sections<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Reference updates (e.g. =
changed RFC
2459 to RFC 3280)<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>domainComponent attribute =
added to
subject field attribute list<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>title attribute added to =
subject
field attribute list<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>postalAddress removed from =
subject
field attribute list<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>title removed from
subjectDirectoryAttribute extension attribute =
list<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Key usage: Recommendation =
that NR
SHOULD be exclusive if set has been removed<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Scope update of =
qcStatements
extension<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>It is important to note that NO syntax changes has =
been made
to the document.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Further actions before producing =
RFC:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>- finalize reference updates (X.509 is still old =
reference)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>- Finalize ASN.1 parts (get new assigned =
numbers)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><u><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Recommendations from ETSI STF 220 =
Task 3<o:p></o:p></span></font></u></b></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Following is the section 2 from the STF 220 Task 3
requirements document. The whole document can be obtained from me upon =
request.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2&nbsp;&nbsp; =
Recommendations on RFC
3039 updates <o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>As part of this task, STF will seek to influence the update of =
RFC 3039
to adapt the following changes:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2.1 =
Scope<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>RFC 3039 defines a number of aspects that are generic for both
Qualified Certificates as well as certificates to physical persons that =
are not
&#8220;Qualified&#8221;. Examples are defined attributes, biometricInfo
extension, and aspects of the qcStatements extension. The scope of RFC =
3039
should be updated to more clearly reflect this reality, as well as other =
proposed
changes to the profile.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2.2 =
References<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>References need to be updated. E.g. from RFC 2459 to RFC =
3280<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2.3 Key =
usage<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>As a result of generalizing RFC 3039, the current requirement of =
having
non-repudiation exclusive if set, becomes too specific and cause =
confusion in
term of for which cases this applies and which cases it does not. This =
has
shown to diminish the use of other functions of RFC 3039 in certificates =
where
RFC 3039 in general applies, but this paragraph does =
not.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2.4 Subject =
field<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>The set of attributes should be =
updated.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>postalAddress should be removed from the list of attributes in =
the
subject field and title attribute should be included and removed from =
the
subjectDirectoryAttributes extension.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>PostalAddress is not supported by RFC 3280 for use in the =
subject field
and no records of its use in the subject field in public certificates, =
as a
distinguishing attribute, has been encountered. It is also a structured
attribute and therefore not appropriate for use as an RDN. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Title on the other hand is frequently used. The common place to =
put
this attribute is in the subject field. Since we recommend against use =
of the
subjectDirectoryAttribute extension, the recommended location of the =
title
attribute should be in the subject field.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>domainComponent attribute should be added to the list of =
distingushing
subject attributes. This attribute is commonly used in Subject field, =
primary
as alternative to Country and Organization.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2.5 qcStatements =
extension<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>The defined scope of this extension should be considered for =
update and
adaptation to its current and potential =
use.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>The important thing is thus to preserve the syntax of the =
qcStatements
extension in order to secure backwards compatibility. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C39D4E.6E308D7D--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SApbI7073143 for <[e-mail]>; Tue, 28 Oct 2003 02:51:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SApbNH073142 for ietf-pkix-bks; Tue, 28 Oct 2003 02:51:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SApYI7073128 for <[e-mail]>; Tue, 28 Oct 2003 02:51:35 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA05258 for <[e-mail]>; Tue, 28 Oct 2003 11:51:27 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 28 Oct 2003 11:51:27 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id h9SApQ418171 for [e-mail]; Tue, 28 Oct 2003 11:51:26 +0100 (MET)
Date: Tue, 28 Oct 2003 11:51:26 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: Request change in son-of-rfc2633
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I always thought that the semantics of an SKID/AKID pair
(if keyidentifier is used) of just an AKID(choice issue/serial)
is the following:

During path building among all certificates that have the
chain correctly with the issuer/subject take all those
as candidates that have the same public key as the
one that is identified by the SKID/AKID. 

This is done in order to avoid unnecessary verification
of the certificate signature for all candidates.

Peter
  


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S6IpI7001649 for <[e-mail]>; Mon, 27 Oct 2003 22:18:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S6Ip7M001648 for ietf-pkix-bks; Mon, 27 Oct 2003 22:18:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S6IoI7001637 for <[e-mail]>; Mon, 27 Oct 2003 22:18:50 -0800 (PST) (envelope-from [e-mail])
Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 31317905 for [e-mail]; Tue, 28 Oct 2003 00:18:53 -0600
Date: Tue, 28 Oct 2003 00:18:52 -0600 (CST)
From: Eric Norman <[e-mail]>
To: PKIX list <[e-mail]>
Subject: RE: Request change in son-of-rfc2633
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 28 Oct 2003, Peter Gutmann wrote:

> As was almost everyone else.  The problem is that there are two incompatible
> interpretations of the sKID:
>
> 1. Alternative chaining mechanism if chaining by DN fails, e.g. with cert
>    reparenting or some types of spaghetti PKIs.
>
> 2. Disambiguating factor if chaining by DN leads to multiple issuers, e.g.
>    with other types of spaghetti PKIs.

Is there a claim (#1 above) that you can have the DN in the subject of a
parent's (signer's) certificate be different from (as in different bunch
of bytes) the DN in the issuer of one of its offspring and yet the chain
is still valid because the xKIDs match?  That doesn't seem like an
incompatible interpretation; it seems more like a totally unreasonable
(as in incorrect) interpretation.

Even if some issuer were changing its name but not its signing key, the
old certificates with the old name in the subject field would still be
used, wouldn't they?

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RMBCI7077802 for <[e-mail]>; Mon, 27 Oct 2003 14:11:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RMBCwl077801 for ietf-pkix-bks; Mon, 27 Oct 2003 14:11:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RMB7I7077786 for <[e-mail]>; Mon, 27 Oct 2003 14:11:08 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19517; Mon, 27 Oct 2003 17:10:57 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-12.txt
Date: Mon, 27 Oct 2003 17:10:56 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure: Logotypes in X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-12.txt
	Pages		: 23
	Date		: 2003-10-24
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [e-mail]
mailing list.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-logotypes-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-logotypes-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-logotypes-12.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REInI7052141 for <[e-mail]>; Mon, 27 Oct 2003 06:18:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9REInpX052140 for ietf-pkix-bks; Mon, 27 Oct 2003 06:18:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REImI7052135 for <[e-mail]>; Mon, 27 Oct 2003 06:18:49 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14519; Mon, 27 Oct 2003 09:18:38 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-12.txt
Date: Mon, 27 Oct 2003 09:18:38 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure: Logotypes in X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-12.txt
	Pages		: 23
	Date		: 2003-10-24
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [e-mail]
mailing list.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-logotypes-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-logotypes-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-logotypes-12.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REImI7052133 for <[e-mail]>; Mon, 27 Oct 2003 06:18:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9REImWc052132 for ietf-pkix-bks; Mon, 27 Oct 2003 06:18:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REIjI7052125 for <[e-mail]>; Mon, 27 Oct 2003 06:18:46 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14506; Mon, 27 Oct 2003 09:18:35 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-12.txt
Date: Mon, 27 Oct 2003 09:18:35 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure: Logotypes in X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-12.txt
	Pages		: 23
	Date		: 2003-10-24
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [e-mail]
mailing list.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-logotypes-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-logotypes-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-logotypes-12.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R8bNI7011441 for <[e-mail]>; Mon, 27 Oct 2003 00:37:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9R8bN66011440 for ietf-pkix-bks; Mon, 27 Oct 2003 00:37:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R8bJI7011402 for <[e-mail]>; Mon, 27 Oct 2003 00:37:21 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA37878; Mon, 27 Oct 2003 09:43:20 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA02407; Mon, 27 Oct 2003 09:38:56 +0100
Message-ID: <[e-mail]>
Date: Mon, 27 Oct 2003 09:37:04 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Last Call: 'Warranty Certificate Extension' to  Informational RFC
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

It is normal that your own "mail archive does not show any message to the 
IESG regarding this document" since the e-mail was NOT sent to you directly 
since the original message said:

"send any comments to the [e-mail] or [e-mail]"

So my message was sent to these both addresses in due time, with a copy to 
the PKIX co-chairs.

Denis


> The message below was sent to the PKIX mail list, and it clearly 
> indicates that the document was submitted to the IESG by the chairs.  
> And, it clearly asks for comments to be sent to the IESG.  My mail 
> archive does not show any message from you to the IESG regarding this 
> document.
> 
> Russ
> 
>> To: IETF-Announce: ;
>> Cc: [e-mail]
>> From: The IESG <[e-mail]>
>> Subject: Last Call: 'Internet X.509 Public Key Infrastructure Warranty
>>          Certificate Extension' to Informational RFC
>> Reply-To: [e-mail]
>> Date: Tue, 12 Aug 2003 14:44:07 -0400
>> Sender: [e-mail]
>>
>> The IESG has received a request from the Public-Key Infrastructure 
>> (X.509)
>> WG to consider 'Internet X.509 Public Key Infrastructure Warranty
>> Certificate Extension' <draft-ietf-pkix-warranty-extn-03.txt> as an
>> Informational RFC.
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send any comments to the
>> [e-mail] or [e-mail] mailing lists by 2003-08-26.
>>
>>
>> File(s) can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-03.txt
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QGavI7022944 for <[e-mail]>; Sun, 26 Oct 2003 08:36:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9QGavkg022943 for ietf-pkix-bks; Sun, 26 Oct 2003 08:36:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QGauI7022937 for <[e-mail]>; Sun, 26 Oct 2003 08:36:56 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sun, 26 Oct 2003 11:36:51 -0500
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Oops, now I understand the scenario Steve Hanna was referring to:
   1. Subject CA picks it's own AKI using a computation
      technique, assuming issing CAs will use the same value
      for SKI (as they should).
   2. Issuing CA issues a cross-cert with an SKI using a different
      computation technique, blindly assuming that subject CA will
      take what he has been given to use as AKI as if subject were
      a child in issuer's hierarchy.

Sorry, Steve for my rant.  A working system has to have a common
set of assumptions, such as SKIs flow from the top down (works only
for hierarchies), or SKIs flow from the subject CAs to the issuers
(works in any topology), or every CA uses the same SKI computation
technique (works in any topology).  I didn't consider the situation
where the issuing CA and subject CA operate using different concepts
of who does what to whom.  Thanks, Stefan, for pointing out that
some CAs that were designed for use only in hierarchies are being
misused to issue cross certificates.

Dave



Stefan Santesson wrote:

> The problem is that RFC 3280 in practice require a CA, issuing a CA
> certs, to ask the subordinate CA for its preferred SKI rather than
> generating it.
> 
> To my knowledge there is no CA software that has implemented that
> behavior. If I'm not wrong they are all counting on that subordinate CAs
> will adopt the SKI generated by the parent CA, as the AKI placed in
> issued certs.
> 
> This works for strict hierarchical structures but not for generic cross
> certification (such as Bridge CA) unless CAs use the same SKI generation
> algorithm.
> 
> /Stefan
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of David P. Kemp
>>Sent: den 25 oktober 2003 00:54
>>To: [e-mail]
>>Subject: Re: AKI and SKI problem with RFC 3280?
>>
>>
>>Santosh,
>>
>>I agree that Section 4.2.1.2 of 3280 unambiguously states
>>that an "issuing CA" that does not populate SKI with the value
>>of AKI used by the "subject CA" is not compliant.
>>
>>It appeared that Steve Hanna was referring to non-3280-compliant
>>CAs, where
>>   "the CA certificate may have been issued by a CA that uses
>>    a different AKI/SKI computation technique than the CA
>>    who's the subject of the CA certificate."
>>
>>A compliant "subject CA" may have an AKI computation technique,
>>but a compliant "issuing CA" must not have an SKI computation
>>technique for CA certs - it must import the subject CA's AKI.
>>
>>Outside the realm of 3280 compliance, where the situation
>>of N different SKIs might occur and AKI/SKI don't necessarily
>>chain, the chaining problem occurs when two issuing CAs use
>>two different computation techniques to assign SKIs to the
>>subject, *not* when the issuing CA uses a different technique
>>than the subject CA.  The subject CA's techniques for choosing
>>an AKI for itself and SKIs to go in its issued certs is
>>completely irrelevant.
>>
>>Dave
>>
>>
>>Santosh Chokhani wrote:
>>
>>>David:
>>>
>>>Some of us are interpreting 3280 (specifically Section
> 
> 4.2.1.2,Subject
> 
>>Key
>>
>>>Identifier) to state that all N SKI should be the same and match the
> 
> AKI
> 
>>>used by the subject CA in the certificates it issues.  If not, the
> 
> CAs
> 
>>that
>>
>>>do not populate the
>>>SKI, may not be RFC 3280 compliant.
>>>
>>>Thus, your suggestion of the subject CA using one of the SKI is a
> 
> more
> 
>>>liberal interpretation of 3280 and is covered by our interpretation
> 
> of
> 
>>3280.
>>
>>>At the risk of being redundant, if all CAs are 3280 compliant all N
> 
> SKI
> 
>>in N
>>
>>>certificates issued to a CA for the same SPKI X == AKI in all
>>
>>certificates
>>
>>>signed by the CA, where the signature can be verified using X
>>>
>>>-----Original Message-----
>>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On
>>
>>>Behalf Of David P. Kemp
>>>Sent: Friday, October 24, 2003 12:19 PM
>>>To: [e-mail]
>>>Subject: Re: AKI and SKI problem with RFC 3280?
>>>
>>>
>>>
>>>Isn't the raison d'etre of AKI/SKI to allow a verifier
>>>to select the correct CA cert when multiple certs of the
>>>same issuer with different public keys are available
>>>(i.e. during rollover)?
>>>
>>>A CA may use any computation technique to populate the
>>>SKI of certs that it issues, but it MUST chain its own
>>>SKI into the AKI of certs that it issues.  Otherwise
>>>what's the point of populating AKI at all?
>>>
>>>The reason AKI/SKI chaining MUST NOT be enforced during
>>>path validation is because one CA could have one
>>>signing public key identified by N different SKIs
>>>in N different certs. (That's a bad thang, and cross-certificates
> 
> should
> 
>>>follow precedent rather than using a different SKI for the same
> 
> public
> 
>>key.)
>>
>>>But the CA MUST choose one of it's N SKIs to use as AKI, not make up
>>
>>some
>>
>>>different N+1th value. If it picks one of the N, then AKI is helpful
>>
>>1/Nth
>>
>>>of the time.  If it picks something else, then AKI can never be
> 
> helpful.
> 
>>>Dave
>>>
>>>
>>>Steve Hanna wrote:
>>>
>>>
>>>
>>>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>>>during path validation. To be more explicit, it's
>>>>NOT true that the SKI of a CA certificate must match
>>>>the AKI of a certificate signed by that CA. Why?
>>>>Because the CA certificate may have been issued by
>>>>a CA that uses a different AKI/SKI computation technique
>>>>than the CA who's the subject of the CA certificate.
>>>
>>>
>>>
>>>
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QFhtI7020650 for <[e-mail]>; Sun, 26 Oct 2003 07:43:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9QFhtrT020649 for ietf-pkix-bks; Sun, 26 Oct 2003 07:43:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QFhsI7020642 for <[e-mail]>; Sun, 26 Oct 2003 07:43:54 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sun, 26 Oct 2003 10:43:44 -0500
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stefan,

Someone (sorry, I looked back through this thread but couldn't find it) 
said "we all know what's right; the question is what do real products do 
about it?"  In this instance, doing it the way real products do it is 
not useful, and a standard has no choice but to stand up for what's right.

Saying "this CA behavior works for hierarchies but not for meshes" is 
equivalent to saying "the AKI/SKI extensions work for hierarchies but 
not for meshes".  It is theoretically impossible for AKI/SKI to work 
reliably (i.e. 100% of the time instead of 1/N of the time) unless all 
CAs that issue CA certs implement chaining.

For the first subject CA cert there are two timing options: either the 
subject CA first picks its own AKI and issues some certs and then the 
issuing CA imports subject's SKI, or the issuing CA picks SKI first and 
then subject CA uses it for AKI.  But for all remaining subject CA certs 
(cross-certs) there is only one useful option - use the subject's 
existing AKI as SKI.  The cross-certifying CAs must either use subject's 
AKI or they must issue the cross-cert without an SKI extension; the 
third option of picking an SKI using some computation technique other 
than the one already used for the subject CA is a worthless and 
misleading waste of bits - it can cause RPs to discard valid paths 
(potentially the only valid path for that RP) during path construction.

I vote for keeping 3280 the way it is.  But if it is changed, it should 
say conforming CAs MUST NOT populate SKI unless they do it as specified 
in 4.2.1.2.  Fixing every CA is surely easier than "fixing" every 
application to do path construction by checking signatures, including 
even paths with the wrong SKIs.

Dave



Stefan Santesson wrote:
> The problem is that RFC 3280 in practice require a CA, issuing a CA
> certs, to ask the subordinate CA for its preferred SKI rather than
> generating it.
> 
> To my knowledge there is no CA software that has implemented that
> behavior. If I'm not wrong they are all counting on that subordinate CAs
> will adopt the SKI generated by the parent CA, as the AKI placed in
> issued certs.
> 
> This works for strict hierarchical structures but not for generic cross
> certification (such as Bridge CA) unless CAs use the same SKI generation
> algorithm.
> 
> /Stefan
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of David P. Kemp
>>Sent: den 25 oktober 2003 00:54
>>To: [e-mail]
>>Subject: Re: AKI and SKI problem with RFC 3280?
>>
>>
>>Santosh,
>>
>>I agree that Section 4.2.1.2 of 3280 unambiguously states
>>that an "issuing CA" that does not populate SKI with the value
>>of AKI used by the "subject CA" is not compliant.
>>
>>It appeared that Steve Hanna was referring to non-3280-compliant
>>CAs, where
>>   "the CA certificate may have been issued by a CA that uses
>>    a different AKI/SKI computation technique than the CA
>>    who's the subject of the CA certificate."
>>
>>A compliant "subject CA" may have an AKI computation technique,
>>but a compliant "issuing CA" must not have an SKI computation
>>technique for CA certs - it must import the subject CA's AKI.
>>
>>Outside the realm of 3280 compliance, where the situation
>>of N different SKIs might occur and AKI/SKI don't necessarily
>>chain, the chaining problem occurs when two issuing CAs use
>>two different computation techniques to assign SKIs to the
>>subject, *not* when the issuing CA uses a different technique
>>than the subject CA.  The subject CA's techniques for choosing
>>an AKI for itself and SKIs to go in its issued certs is
>>completely irrelevant.
>>
>>Dave
>>
>>
>>Santosh Chokhani wrote:
>>
>>>David:
>>>
>>>Some of us are interpreting 3280 (specifically Section
> 
> 4.2.1.2,Subject
> 
>>Key
>>
>>>Identifier) to state that all N SKI should be the same and match the
> 
> AKI
> 
>>>used by the subject CA in the certificates it issues.  If not, the
> 
> CAs
> 
>>that
>>
>>>do not populate the
>>>SKI, may not be RFC 3280 compliant.
>>>
>>>Thus, your suggestion of the subject CA using one of the SKI is a
> 
> more
> 
>>>liberal interpretation of 3280 and is covered by our interpretation
> 
> of
> 
>>3280.
>>
>>>At the risk of being redundant, if all CAs are 3280 compliant all N
> 
> SKI
> 
>>in N
>>
>>>certificates issued to a CA for the same SPKI X == AKI in all
>>
>>certificates
>>
>>>signed by the CA, where the signature can be verified using X
>>>
>>>-----Original Message-----
>>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On
>>
>>>Behalf Of David P. Kemp
>>>Sent: Friday, October 24, 2003 12:19 PM
>>>To: [e-mail]
>>>Subject: Re: AKI and SKI problem with RFC 3280?
>>>
>>>
>>>
>>>Isn't the raison d'etre of AKI/SKI to allow a verifier
>>>to select the correct CA cert when multiple certs of the
>>>same issuer with different public keys are available
>>>(i.e. during rollover)?
>>>
>>>A CA may use any computation technique to populate the
>>>SKI of certs that it issues, but it MUST chain its own
>>>SKI into the AKI of certs that it issues.  Otherwise
>>>what's the point of populating AKI at all?
>>>
>>>The reason AKI/SKI chaining MUST NOT be enforced during
>>>path validation is because one CA could have one
>>>signing public key identified by N different SKIs
>>>in N different certs. (That's a bad thang, and cross-certificates
> 
> should
> 
>>>follow precedent rather than using a different SKI for the same
> 
> public
> 
>>key.)
>>
>>>But the CA MUST choose one of it's N SKIs to use as AKI, not make up
>>
>>some
>>
>>>different N+1th value. If it picks one of the N, then AKI is helpful
>>
>>1/Nth
>>
>>>of the time.  If it picks something else, then AKI can never be
> 
> helpful.
> 
>>>Dave
>>>
>>>
>>>Steve Hanna wrote:
>>>
>>>
>>>
>>>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>>>during path validation. To be more explicit, it's
>>>>NOT true that the SKI of a CA certificate must match
>>>>the AKI of a certificate signed by that CA. Why?
>>>>Because the CA certificate may have been issued by
>>>>a CA that uses a different AKI/SKI computation technique
>>>>than the CA who's the subject of the CA certificate.
>>>
>>>
>>>
>>>
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QF3pI7019168 for <[e-mail]>; Sun, 26 Oct 2003 07:03:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9QF3pt4019167 for ietf-pkix-bks; Sun, 26 Oct 2003 07:03:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QF3oI7019161 for <[e-mail]>; Sun, 26 Oct 2003 07:03:50 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (58.arlington-31-32rs.va.dial-access.att.net[12.92.108.58]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003102615034411100ilmq8e>; Sun, 26 Oct 2003 15:03:44 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Sun, 26 Oct 2003 10:03:34 -0500
Message-ID: <001501c39bd2$58d69080$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David:

The problem of different CAs populating different SKI is the reason path
development by the relying parties should not require AKI/SKI match, but
rather use AKI/SKI match as a prioritization or weighting function.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of David P. Kemp
Sent: Friday, October 24, 2003 6:54 PM
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?



Santosh,

I agree that Section 4.2.1.2 of 3280 unambiguously states
that an "issuing CA" that does not populate SKI with the value of AKI used
by the "subject CA" is not compliant.

It appeared that Steve Hanna was referring to non-3280-compliant CAs, where
   "the CA certificate may have been issued by a CA that uses
    a different AKI/SKI computation technique than the CA
    who's the subject of the CA certificate."

A compliant "subject CA" may have an AKI computation technique, but a
compliant "issuing CA" must not have an SKI computation technique for CA
certs - it must import the subject CA's AKI.

Outside the realm of 3280 compliance, where the situation
of N different SKIs might occur and AKI/SKI don't necessarily chain, the
chaining problem occurs when two issuing CAs use two different computation
techniques to assign SKIs to the subject, *not* when the issuing CA uses a
different technique than the subject CA.  The subject CA's techniques for
choosing an AKI for itself and SKIs to go in its issued certs is completely
irrelevant.

Dave


Santosh Chokhani wrote:
> David:
> 
> Some of us are interpreting 3280 (specifically Section 4.2.1.2,Subject 
> Key
> Identifier) to state that all N SKI should be the same and match the AKI
> used by the subject CA in the certificates it issues.  If not, the CAs
that
> do not populate the 
> SKI, may not be RFC 3280 compliant.
> 
> Thus, your suggestion of the subject CA using one of the SKI is a more 
> liberal interpretation of 3280 and is covered by our interpretation of 
> 3280. At the risk of being redundant, if all CAs are 3280 compliant 
> all N SKI in N certificates issued to a CA for the same SPKI X == AKI 
> in all certificates signed by the CA, where the signature can be 
> verified using X
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of David P. Kemp
> Sent: Friday, October 24, 2003 12:19 PM
> To: [e-mail]
> Subject: Re: AKI and SKI problem with RFC 3280?
> 
> 
> 
> Isn't the raison d'etre of AKI/SKI to allow a verifier
> to select the correct CA cert when multiple certs of the
> same issuer with different public keys are available
> (i.e. during rollover)?
> 
> A CA may use any computation technique to populate the
> SKI of certs that it issues, but it MUST chain its own
> SKI into the AKI of certs that it issues.  Otherwise
> what's the point of populating AKI at all?
> 
> The reason AKI/SKI chaining MUST NOT be enforced during
> path validation is because one CA could have one
> signing public key identified by N different SKIs
> in N different certs. (That's a bad thang, and cross-certificates 
> should follow precedent rather than using a different SKI for the same 
> public key.) But the CA MUST choose one of it's N SKIs to use as AKI, 
> not make up some different N+1th value. If it picks one of the N, then 
> AKI is helpful 1/Nth of the time.  If it picks something else, then 
> AKI can never be helpful.
> 
> Dave
> 
> 
> Steve Hanna wrote:
> 
> 
>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>during path validation. To be more explicit, it's
>>NOT true that the SKI of a CA certificate must match
>>the AKI of a certificate signed by that CA. Why?
>>Because the CA certificate may have been issued by
>>a CA that uses a different AKI/SKI computation technique
>>than the CA who's the subject of the CA certificate.
> 
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9PN6JI7017755 for <[e-mail]>; Sat, 25 Oct 2003 16:06:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9PN6J0L017754 for ietf-pkix-bks; Sat, 25 Oct 2003 16:06:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.netscreen.com (mail2.netscreen.com [63.126.135.18]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9PN6II7017747 for <[e-mail]>; Sat, 25 Oct 2003 16:06:18 -0700 (PDT) (envelope-from [e-mail])
Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9PN6EOh002098; Sat, 25 Oct 2003 16:06:15 -0700 (PDT)
Received: by NS-CA.netscreen.com with Internet Mail Service (5.5.2653.19) id <461S13F6>; Sat, 25 Oct 2003 16:06:14 -0700
Message-ID: <[e-mail]>
From: Gregory Lebovitz <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: BOF: pki4ipsec
Date: Sat, 25 Oct 2003 16:06:10 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,
As IPsec working group is finishing up its chartered work, some of the
works-in-progress have been moved to other or new WGs. The effort of
profiling the use of PKI for IPsec is one such effort.

We will start with a BOF in MN. Details below.

Profiling Use of PKI in IPSEC BOF (pki4ipsec)

Thursday, November 13 at 0900-1130
==================================

Full charter and mail list info at:
  http://www.icsalabs.com/pki4ipsec

We are looking forward to your participation!

Gregory Lebovitz (Co-chair)


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9PHhII7006680 for <[e-mail]>; Sat, 25 Oct 2003 10:43:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9PHhIf3006678 for ietf-pkix-bks; Sat, 25 Oct 2003 10:43:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9PHhEI7006600 for <[e-mail]>; Sat, 25 Oct 2003 10:43:14 -0700 (PDT) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 25 Oct 2003 18:43:06 +0100
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 25 Oct 2003 18:43:05 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 25 Oct 2003 18:43:05 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Sat, 25 Oct 2003 18:41:23 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AKI and SKI problem with RFC 3280?
Thread-Index: AcOajCat2kZWqCl5SCecQsXUFOs2QwAkbnhg
From: "Stefan Santesson" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 25 Oct 2003 17:43:05.0753 (UTC) FILETIME=[72208090:01C39B1F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9PHhFI7006631
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The problem is that RFC 3280 in practice require a CA, issuing a CA
certs, to ask the subordinate CA for its preferred SKI rather than
generating it.

To my knowledge there is no CA software that has implemented that
behavior. If I'm not wrong they are all counting on that subordinate CAs
will adopt the SKI generated by the parent CA, as the AKI placed in
issued certs.

This works for strict hierarchical structures but not for generic cross
certification (such as Bridge CA) unless CAs use the same SKI generation
algorithm.

/Stefan
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of David P. Kemp
> Sent: den 25 oktober 2003 00:54
> To: [e-mail]
> Subject: Re: AKI and SKI problem with RFC 3280?
> 
> 
> Santosh,
> 
> I agree that Section 4.2.1.2 of 3280 unambiguously states
> that an "issuing CA" that does not populate SKI with the value
> of AKI used by the "subject CA" is not compliant.
> 
> It appeared that Steve Hanna was referring to non-3280-compliant
> CAs, where
>    "the CA certificate may have been issued by a CA that uses
>     a different AKI/SKI computation technique than the CA
>     who's the subject of the CA certificate."
> 
> A compliant "subject CA" may have an AKI computation technique,
> but a compliant "issuing CA" must not have an SKI computation
> technique for CA certs - it must import the subject CA's AKI.
> 
> Outside the realm of 3280 compliance, where the situation
> of N different SKIs might occur and AKI/SKI don't necessarily
> chain, the chaining problem occurs when two issuing CAs use
> two different computation techniques to assign SKIs to the
> subject, *not* when the issuing CA uses a different technique
> than the subject CA.  The subject CA's techniques for choosing
> an AKI for itself and SKIs to go in its issued certs is
> completely irrelevant.
> 
> Dave
> 
> 
> Santosh Chokhani wrote:
> > David:
> >
> > Some of us are interpreting 3280 (specifically Section
4.2.1.2,Subject
> Key
> > Identifier) to state that all N SKI should be the same and match the
AKI
> > used by the subject CA in the certificates it issues.  If not, the
CAs
> that
> > do not populate the
> > SKI, may not be RFC 3280 compliant.
> >
> > Thus, your suggestion of the subject CA using one of the SKI is a
more
> > liberal interpretation of 3280 and is covered by our interpretation
of
> 3280.
> > At the risk of being redundant, if all CAs are 3280 compliant all N
SKI
> in N
> > certificates issued to a CA for the same SPKI X == AKI in all
> certificates
> > signed by the CA, where the signature can be verified using X
> >
> > -----Original Message-----
> > From: [e-mail]
[mailto:[e-mail]]
> On
> > Behalf Of David P. Kemp
> > Sent: Friday, October 24, 2003 12:19 PM
> > To: [e-mail]
> > Subject: Re: AKI and SKI problem with RFC 3280?
> >
> >
> >
> > Isn't the raison d'etre of AKI/SKI to allow a verifier
> > to select the correct CA cert when multiple certs of the
> > same issuer with different public keys are available
> > (i.e. during rollover)?
> >
> > A CA may use any computation technique to populate the
> > SKI of certs that it issues, but it MUST chain its own
> > SKI into the AKI of certs that it issues.  Otherwise
> > what's the point of populating AKI at all?
> >
> > The reason AKI/SKI chaining MUST NOT be enforced during
> > path validation is because one CA could have one
> > signing public key identified by N different SKIs
> > in N different certs. (That's a bad thang, and cross-certificates
should
> > follow precedent rather than using a different SKI for the same
public
> key.)
> > But the CA MUST choose one of it's N SKIs to use as AKI, not make up
> some
> > different N+1th value. If it picks one of the N, then AKI is helpful
> 1/Nth
> > of the time.  If it picks something else, then AKI can never be
helpful.
> >
> > Dave
> >
> >
> > Steve Hanna wrote:
> >
> >
> >>Note also that AKI/SKI chaining SHOULD NOT be checked
> >>during path validation. To be more explicit, it's
> >>NOT true that the SKI of a CA certificate must match
> >>the AKI of a certificate signed by that CA. Why?
> >>Because the CA certificate may have been issued by
> >>a CA that uses a different AKI/SKI computation technique
> >>than the CA who's the subject of the CA certificate.
> >
> >
> >
> >
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OMs4I7099036 for <[e-mail]>; Fri, 24 Oct 2003 15:54:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OMs4oG099035 for ietf-pkix-bks; Fri, 24 Oct 2003 15:54:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OMs3I7099023 for <[e-mail]>; Fri, 24 Oct 2003 15:54:03 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 24 Oct 2003 18:53:53 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <00c601c39a6c$769d1f60$[e-mail]>
In-Reply-To: <00c601c39a6c$769d1f60$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

I agree that Section 4.2.1.2 of 3280 unambiguously states
that an "issuing CA" that does not populate SKI with the value
of AKI used by the "subject CA" is not compliant.

It appeared that Steve Hanna was referring to non-3280-compliant
CAs, where
   "the CA certificate may have been issued by a CA that uses
    a different AKI/SKI computation technique than the CA
    who's the subject of the CA certificate."

A compliant "subject CA" may have an AKI computation technique,
but a compliant "issuing CA" must not have an SKI computation
technique for CA certs - it must import the subject CA's AKI.

Outside the realm of 3280 compliance, where the situation
of N different SKIs might occur and AKI/SKI don't necessarily
chain, the chaining problem occurs when two issuing CAs use
two different computation techniques to assign SKIs to the
subject, *not* when the issuing CA uses a different technique
than the subject CA.  The subject CA's techniques for choosing
an AKI for itself and SKIs to go in its issued certs is
completely irrelevant.

Dave


Santosh Chokhani wrote:
> David:
> 
> Some of us are interpreting 3280 (specifically Section 4.2.1.2,Subject Key
> Identifier) to state that all N SKI should be the same and match the AKI
> used by the subject CA in the certificates it issues.  If not, the CAs that
> do not populate the 
> SKI, may not be RFC 3280 compliant.
> 
> Thus, your suggestion of the subject CA using one of the SKI is a more
> liberal interpretation of 3280 and is covered by our interpretation of 3280.
> At the risk of being redundant, if all CAs are 3280 compliant all N SKI in N
> certificates issued to a CA for the same SPKI X == AKI in all certificates
> signed by the CA, where the signature can be verified using X
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of David P. Kemp
> Sent: Friday, October 24, 2003 12:19 PM
> To: [e-mail]
> Subject: Re: AKI and SKI problem with RFC 3280?
> 
> 
> 
> Isn't the raison d'etre of AKI/SKI to allow a verifier
> to select the correct CA cert when multiple certs of the
> same issuer with different public keys are available
> (i.e. during rollover)?
> 
> A CA may use any computation technique to populate the
> SKI of certs that it issues, but it MUST chain its own
> SKI into the AKI of certs that it issues.  Otherwise
> what's the point of populating AKI at all?
> 
> The reason AKI/SKI chaining MUST NOT be enforced during
> path validation is because one CA could have one
> signing public key identified by N different SKIs
> in N different certs. (That's a bad thang, and cross-certificates should
> follow precedent rather than using a different SKI for the same public key.)
> But the CA MUST choose one of it's N SKIs to use as AKI, not make up some
> different N+1th value. If it picks one of the N, then AKI is helpful 1/Nth
> of the time.  If it picks something else, then AKI can never be helpful.
> 
> Dave
> 
> 
> Steve Hanna wrote:
> 
> 
>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>during path validation. To be more explicit, it's
>>NOT true that the SKI of a CA certificate must match
>>the AKI of a certificate signed by that CA. Why?
>>Because the CA certificate may have been issued by
>>a CA that uses a different AKI/SKI computation technique
>>than the CA who's the subject of the CA certificate.
> 
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OKLrI7094546 for <[e-mail]>; Fri, 24 Oct 2003 13:21:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OKLrTo094545 for ietf-pkix-bks; Fri, 24 Oct 2003 13:21:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OKLqI7094540 for <[e-mail]>; Fri, 24 Oct 2003 13:21:52 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id h9OKLrDb006798 for <[e-mail]>; Fri, 24 Oct 2003 16:21:53 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Fri, 24 Oct 2003 16:21:48 -0400
Message-ID: <00c601c39a6c$769d1f60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9OKLqI7094541
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David:

Some of us are interpreting 3280 (specifically Section 4.2.1.2,Subject Key
Identifier) to state that all N SKI should be the same and match the AKI
used by the subject CA in the certificates it issues.  If not, the CAs that
do not populate the 
SKI, may not be RFC 3280 compliant.

Thus, your suggestion of the subject CA using one of the SKI is a more
liberal interpretation of 3280 and is covered by our interpretation of 3280.
At the risk of being redundant, if all CAs are 3280 compliant all N SKI in N
certificates issued to a CA for the same SPKI X == AKI in all certificates
signed by the CA, where the signature can be verified using X

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of David P. Kemp
Sent: Friday, October 24, 2003 12:19 PM
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?



Isn't the raison d'etre of AKI/SKI to allow a verifier
to select the correct CA cert when multiple certs of the
same issuer with different public keys are available
(i.e. during rollover)?

A CA may use any computation technique to populate the
SKI of certs that it issues, but it MUST chain its own
SKI into the AKI of certs that it issues.  Otherwise
what's the point of populating AKI at all?

The reason AKI/SKI chaining MUST NOT be enforced during
path validation is because one CA could have one
signing public key identified by N different SKIs
in N different certs. (That's a bad thang, and cross-certificates should
follow precedent rather than using a different SKI for the same public key.)
But the CA MUST choose one of it's N SKIs to use as AKI, not make up some
different N+1th value. If it picks one of the N, then AKI is helpful 1/Nth
of the time.  If it picks something else, then AKI can never be helpful.

Dave


Steve Hanna wrote:

> Note also that AKI/SKI chaining SHOULD NOT be checked
> during path validation. To be more explicit, it's
> NOT true that the SKI of a CA certificate must match
> the AKI of a certificate signed by that CA. Why?
> Because the CA certificate may have been issued by
> a CA that uses a different AKI/SKI computation technique
> than the CA who's the subject of the CA certificate.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OHH5I7088127 for <[e-mail]>; Fri, 24 Oct 2003 10:17:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OHH5HW088126 for ietf-pkix-bks; Fri, 24 Oct 2003 10:17:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OHH3I7088119 for <[e-mail]>; Fri, 24 Oct 2003 10:17:04 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft6.fr.colt.net with ESMTP id h9OHGw420285 for <[e-mail]>; Fri, 24 Oct 2003 19:17:03 +0200
Message-ID: <[e-mail]>
Date: Fri, 24 Oct 2003 19:17:36 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031004
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <000601c3990a$863a5b80$6601a8c0@gnosis> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna wrote:

>Some CA software (or maybe just CAs as
>operated) apparently doesn't allow the certificate
>subject to specify what SKI it wants. 
>
Really I'd be surprised  if this was indeed a software limitation.
So who here distribute a CA products that can not be configured to 
attribute the correct SKI to a sub-CA certificate ?
Of course we're talking here about sub-CA and not end-entity certificates.
I don't expect to see certificates for CA delivered from an automatic 
process that can not be tuned, but I could be wrong for some cases of 
cross-certificates.

It would be really good to know if the problem met in interoperability 
tests were due to :
- insufficient attention given to this subject by the CA operator.
- actual limitation of some rarer CA software
- actual limitation of a significant number of popular CA software

I have met at least one product that did not offer a way to copy it 
automatically.
But the key ceremony required to create such a certificate already 
included a one page long description of every single tidbit that would 
go inside the certificate, so adding the exact value of the SKI in case 
it could not be created with one the standard algorithms would have been 
no great deal.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGIdI7085910 for <[e-mail]>; Fri, 24 Oct 2003 09:18:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OGIdEc085909 for ietf-pkix-bks; Fri, 24 Oct 2003 09:18:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGIcI7085904 for <[e-mail]>; Fri, 24 Oct 2003 09:18:38 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 24 Oct 2003 12:18:33 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Isn't the raison d'etre of AKI/SKI to allow a verifier
to select the correct CA cert when multiple certs of the
same issuer with different public keys are available
(i.e. during rollover)?

A CA may use any computation technique to populate the
SKI of certs that it issues, but it MUST chain its own
SKI into the AKI of certs that it issues.  Otherwise
what's the point of populating AKI at all?

The reason AKI/SKI chaining MUST NOT be enforced during
path validation is because one CA could have one
signing public key identified by N different SKIs
in N different certs. (That's a bad thang, and
cross-certificates should follow precedent rather
than using a different SKI for the same public key.)
But the CA MUST choose one of it's N SKIs
to use as AKI, not make up some different N+1th value.
If it picks one of the N, then AKI is helpful 1/Nth
of the time.  If it picks something else, then AKI
can never be helpful.

Dave


Steve Hanna wrote:

> Note also that AKI/SKI chaining SHOULD NOT be checked
> during path validation. To be more explicit, it's
> NOT true that the SKI of a CA certificate must match
> the AKI of a certificate signed by that CA. Why?
> Because the CA certificate may have been issued by
> a CA that uses a different AKI/SKI computation technique
> than the CA who's the subject of the CA certificate.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OEKBI7080886 for <[e-mail]>; Fri, 24 Oct 2003 07:20:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OEKBX3080885 for ietf-pkix-bks; Fri, 24 Oct 2003 07:20:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OEK9I7080879 for <[e-mail]>; Fri, 24 Oct 2003 07:20:10 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9OEKAPh020120 for <[e-mail]>; Fri, 24 Oct 2003 08:20:10 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h9OEK9B05325; Fri, 24 Oct 2003 10:20:09 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 24 Oct 2003 10:19:39 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <000601c3990a$863a5b80$6601a8c0@gnosis>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms855FA98D4191FBC87A6A82DF"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms855FA98D4191FBC87A6A82DF
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

I'll try Peter Gutmann's technique of responding to
several messages at once to reduce the number of messages.

Stefan Santesson wrote:
> And may I also suggest limiting recommendations to
> key identifiers derived from the key hash, unless
> there is a strong need for other solutions not yet
> presented in this debate.

Yes, I think there is universal agreement that
"a monotonically increasing sequence of integers"
SHOULD NOT be used for AKI/SKI. I'd be glad to
see such a recommendation added to the successor
to RFC 3280.

L Williams wrote:
> I think what this thread established was that sane CAs
> should be able to respect existing key identifiers when
> they do cross-certification/bridging. This means that
> AKI/SKI chaining should work the majority of the time,
> not fail the majority of the time. Seems to me that the
> change would be to make this a "SHOULD" not a "SHOULD NOT".

Which SHOULD are you talking about? I suspect you mean
my comment "relying parties SHOULD NOT require AKI/SKI
matching." If so, why do you think that relying parties
SHOULD require AKI/SKI matching? There's no security
benefit to doing so and some significant downsides, as
noted below.

Sharon Boeyen wrote:
> Shouldn't a CA determine what its own key identifier is
> (and 3280 recommends ways to calulate it). Once they have
> their own key id, this value should go into the AKI extension
> of all certificates issued by that CA and should go into
> the SKI extension of all certificates issued to that CA.

I agree that's best. However, it doesn't always work
out that way. Some CA software (or maybe just CAs as
operated) apparently doesn't allow the certificate
subject to specify what SKI it wants. Also, consider
the case where a CA decides to change its AKI (as when
moving away from monotonically increasing integers).
It would be nice to gradually transition from the old
AKI to the new one (without requiring all certificates
to and from the CA to be reissued simultaneously).

I agree with Santosh's earlier comment. We should stick with
the current RFC 3280 statements that CAs MUST use an
SKI in each CA certificate they issue that matches the
AKI used by the subject of the certificate. And we
should add a statement (explicitly stating what was already
implicit) saying that relying parties SHOULD NOT require
this match. It's only a hint for path building.

While I'm at it, I'll respond to one more comment:

Michael Ströder wrote:
> Is there any good reason to set AKI/SKI at all?

Some path building software uses it as a hint to
choose between several certs that look suitable.
Personally, I don't see a big win. As Peter points
out, subject and issuer names are a more reliable
mechanism. They *must* match or the path isn't valid.

Unfortunately, I have heard that some path building
software uses AKI/SKI as a database key and only
finds a path if they match. I've also heard that
some path validation software requires a match.
Both of those are mistakes. What a bummer for the
users! And all the more reason why the successor to
RFC 3280 should be explicit in saying that relying
parties SHOULD NOT require an AKI/SKI match.

So I think AKI/SKI have *some* utility

Thanks,

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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMxMDI0MTQxOTQwWjAjBgkqhkiG9w0BCQQxFgQU0uJLXkIi8I+ZBgw0rVOtvHgc
2yQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAu4JhY
+rPp6x0d7KgsvqHfqQaVTZNMFHTGqUcUVfithFIpPO4HIBZrFbDjNd7bC+ff2QJHfps1612D
q8tmAtPzK3DOYCXQ5V+2sxzH0WQ13GD6IubsO5MOogqYJwubCeVyMq6Et0Nq4yBjZBsEo7RF
9hQZYVZxbVlw1qVg0cq9fQ==
--------------ms855FA98D4191FBC87A6A82DF--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OCNOI7075974 for <[e-mail]>; Fri, 24 Oct 2003 05:23:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OCNOUT075973 for ietf-pkix-bks; Fri, 24 Oct 2003 05:23:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OCNLI7075968 for <[e-mail]>; Fri, 24 Oct 2003 05:23:21 -0700 (PDT) (envelope-from [e-mail])
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h9OCN2e7000984 for <[e-mail]>; Fri, 24 Oct 2003 08:23:02 -0400 (EDT)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.9-20030924/8.12.9) with ESMTP id h9OCN2Sm008243 for <[e-mail]>; Fri, 24 Oct 2003 08:23:02 -0400 (EDT)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.9-20030924/8.12.9/Submit) id h9OCN2uR008242 for [e-mail]; Fri, 24 Oct 2003 08:23:02 -0400 (EDT)
Received: from 151.200.235.112 ( [151.200.235.112]) as user [e-mail] by imp.nist.gov with HTTP; Fri, 24 Oct 2003 08:23:02 -0400
Message-ID: <[e-mail]>
Date: Fri, 24 Oct 2003 08:23:02 -0400
From: [e-mail]
To: [e-mail]
Subject: Agenda Requests
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I am working out the agenda for the PKIX meeting at Minneapolis; my goal is to 
post the draft agenda on Monday.

Please let me know if you would like space on the agenda.  Preference as always 
goes to presentation of PKIX documents and related IETF work.  Time *may* allow 
for a few "liasion" presentations regarding non-IETF work.

Thanks,

Tim Polk



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OAwqI7073251 for <[e-mail]>; Fri, 24 Oct 2003 03:58:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OAwqs1073250 for ietf-pkix-bks; Fri, 24 Oct 2003 03:58:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9OAwpI7073245 for <[e-mail]>; Fri, 24 Oct 2003 03:58:51 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 28883 invoked by uid 0); 24 Oct 2003 10:58:31 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.161.139) by woodstock.binhost.com with SMTP; 24 Oct 2003 10:58:31 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 23 Oct 2003 10:58:26 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Last Call: 'Warranty Certificate Extension' to Informational RFC 
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The message below was sent to the PKIX mail list, and it clearly indicates 
that the document was submitted to the IESG by the chairs.  And, it clearly 
asks for comments to be sent to the IESG.  My mail archive does not show 
any message from you to the IESG regarding this document.

Russ

>To: IETF-Announce: ;
>Cc: [e-mail]
>From: The IESG <[e-mail]>
>Subject: Last Call: 'Internet X.509 Public Key Infrastructure Warranty
>          Certificate Extension' to Informational RFC
>Reply-To: [e-mail]
>Date: Tue, 12 Aug 2003 14:44:07 -0400
>Sender: [e-mail]
>
>The IESG has received a request from the Public-Key Infrastructure (X.509)
>WG to consider 'Internet X.509 Public Key Infrastructure Warranty
>Certificate Extension' <draft-ietf-pkix-warranty-extn-03.txt> as an
>Informational RFC.
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[e-mail] or [e-mail] mailing lists by 2003-08-26.
> 
>
>File(s) can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-03.txt



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NCHXI7060916 for <[e-mail]>; Thu, 23 Oct 2003 05:17:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NCHXsU060915 for ietf-pkix-bks; Thu, 23 Oct 2003 05:17:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NCHUI7060908 for <[e-mail]>; Thu, 23 Oct 2003 05:17:31 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA15158; Thu, 23 Oct 2003 14:23:35 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id OAA18186; Thu, 23 Oct 2003 14:19:08 +0200
Message-ID: <[e-mail]>
Date: Thu, 23 Oct 2003 14:17:22 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>, Russ Housley <[e-mail]>, Steve Bellovin <[e-mail]>
CC: Alice Sturgeon <[e-mail]>, [e-mail], pkix <[e-mail]>
Subject: Re: Last Call: 'Warranty Certificate Extension' to Informational RFC
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On August 26, I sent a reply to the last call sent by the IESG on 
draft-ietf-pkix-warranty-extn-03.txt. It is copied below. Since then, 
nothing happened officially.

I met with Alice Sturgeon yesterday in Paris and we had a talk together. She 
told me that she has also been surprised to see the IESG last call, since 
she was ready to post a new draft 04 to answer my comments. Since she saw 
the IESG last call, she abstained to post it.

Since then, she received comments from the IESG and she needs to post a new 
draft.

I would appreciate if the situation could be clarified either by the 
Security Area Directors or by the PKIX co-chairs.

Denis

============================================================================

>> The IESG has received a request from the Public-Key Infrastructure 
>> (X.509) WG to consider 'Internet X.509 Public Key Infrastructure 
>> Warranty Certificate Extension' <draft-ietf-pkix-warranty-extn-03.txt> 
>> as an Informational RFC.


>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send any comments to the
>> [e-mail] or [e-mail] mailing lists by 2003-08-26.

> I am quite surprised to see that the IESG received a request from the 
> PKIX chairs while a discussion still takes place on the PKIX mailing 
> list on the document.
> 
> The last response from the lead editor (Alice Sturgeon) is dated August 
> 13. She recognizes that at least some "clarifications" are needed.
> 
> The e-mail is duplicated below and exhibits that there is good progress 
> but still no consensus on the document.
> 
> At least some changes to the June version (version 3) are expected 
> before the document can be published.
> 
> Regards,
> 
> Denis
> 
> Note: I am back from holidays, just today (i.e. August 26 th).
> 
> =============================================================================== 
> 
> 
> Hello Denis,
> 
> Please see my comments inserted below, as [AS2], to distinguish from the 
> first set of replies to your original comments.
> 
> Alice
> 
> Alice Sturgeon
> Chair, Canadian Advisory Committee - Information Technology Security
> ISO/IEC JTC 1/SC 27
> and
> System Policy Architect & Manager of Standards
> SPYRUS
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Tuesday, July 29, 2003 6:38 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
> 
> 
> 
> Alice,
> 
> Please see my responses below.
> 
> Comments on warranty-extn-03.txt (June 2003)
> 
> 1- On page 2. The text mentions: "A relying party that has a warranty 
> from a
> CA".
> 
> Does this mean that a relying party must have a contract with the CA to get
> advantage of the warranty ?
> [Alice] No.
> 
> Does this mean that a relying party will get a warranty without a contract
> signed with the CA ?
> [Alice] Yes.
> 
> Does this extension allow to make the difference between the case of a
> signed contract and the case of an unsigned contract where the guarantees
> could be different?
> 
> [Alice] No. If there are any differences in the T&C pertaining to a
> contractual arrangement, these differences will be outside of, beyond the
> scope, and not pertinent to, the warranty offered in the certificate.  It
> applies equally to all relying parties, whether or not a contract has been
> signed.
> 
> [Denis] Then say something like: "Whether or not relying parties have 
> signed
> agreements with CAs, the CA will provide Terms and Conditions for this
> warranty which relates to its liability."
> 
> [AS2] Alternatively, to make the same point, it could remain implicit.
> 
> 2 - The difference between the base warranty and the extended warranty is
> not crystal clear.
> 
> How can a relying party know whether it can have the benefits of the base
> warranty or of the extended warranty ?
> 
> If the extended warranty is present, then the relying party has the benefit
> of the extended warranty.  In short, if it is present, then the relying
> party knows that the relying party has the benefit of the extended warranty
> by its presence alone.  The syntax shows that the extended warranty MAY be
> present:
>   Warranty ::= CHOICE  {
>         none                 NULL,            -- No warranty provided
>         wData                WarrantyData  }  -- Explicit warranty
> 
>     WarrantyData ::= SEQUENCE  {
>         base                 WarrantyInfo,
>         extended             WarrantyInfo OPTIONAL,
>         tcURL                TermsAndConditionsURL OPTIONAL  }
> 
> If the tcURL is present, a human being might understand the terms and
> conditions (if he can understand the local language used), but a computer
> program will not be able to do so. This means that computers cannot
> understand the difference.
> 
> [Alice] The computer does not need to know what is in the T&C.  If the 
> tcURL
> is present, it is optionally for the benefit of the human reader. Perhaps
> you could suggest some text to clarify this in the I-D if you still 
> think it
> is needed.
> 
> [Denis] Then say something like: "Warranty extensions are only aimed for
> human interpretation and contain data that is inappropriate for computer
> based verification schemes, the warranty extension MUST NOT be an active
> component in automated certification path validation."
> 
> [AS2] But this is not necessarily true. It may be that the RP (i.e., the 
> human) has to go to a T&C document if the extended warranty is present, 
> if the RP wants to know what exactly is in the T&C, but there should be 
> the option of not going to the T&C.  If the extended warranty is not 
> present (as noted in the syntax, it is optional), then there is no 
> reason that the extension could not be processed by the computer. 
> Therefore, the warranty extension is NOT "only aimed for human 
> interpretation...".  This may be irrelevant to the point of automated 
> certificate path validation, because the extension is non-critical.
> 
> 3 - There is no security on the information placed at the tcURL parameter
> since no hash of the terms and conditions is being used. These conditions
> could change overtime and relying parties would not be able to demonstrate
> that they have changed.
> 
> [Alice]
> It seems to me that the time stamp on the certificate would suffice to 
> place
> the warranty in a point of time at which the specified terms and conditions
> applied; there is no need for the extension to demonstrate that as this is
> covered by the certificate itself.  This is no different from the
> paper-based world in that if an insurance policy changes its terms, it
> cannot do so retroactively to the detriment of clients who have paid for a
> specific coverage, unless it notified the clients and compensates them
> accordingly.
> 
> [Denis] The problem is that the CA could change the policy and the relying
> party will be unable to demonstrate that the policy has changed. A
> time-stamp token over the certificate would not help. A time-stamp token
> over the T&C would help, but the relying party does not necessarily have
> access to one TSU. The hash approach is much simpler.
> 
> [AS2] A hash function on the T&C?
> 
> 4 - Is the "Relying party Agreement" a document to signed by the parties or
> not ? This should be said.
> 
> [Alice]
> Use of the term "Relying Party Agreement" is no different from its normal
> usage, just as "Certificate Policy" is used in the same context without any
> change to the meaning from normal usage, as per RFC 2527 and its successor.
> In other words, defining the terms, either Relying Party Agreement or
> Certificate Policy is not necessary to the understanding of this extension.
> 
> [Denis] The term "Relying Party Agreement" is confusing. Use a wording like
> "Terms and Conditions for Relying parties" which does not imply that there
> is an agreement signed but that unilaterally the CA provides terms and
> conditions. Relying parties may like them or not. If they disagree with
> them, then this is still "Terms and Conditions for Relying parties".
> 
> [AS2] Maybe so, but the RP has the option of not using or relying on the 
> certificate. As I said before, this is normal terminology, and should 
> not be confusing; it is not being used with a different meaning.
> 
> 5 - The WarrantyValidityPeriod is insufficient. Usually there is a 
> period to
> claim for a compensation which must be made X months or Y days after the
> date of the event which created the damage. It is thus not possible to ask
> for a warranty during e.g. the whole validity period of the certificate.
> Another time period parameter is missing.
> 
> [Alice]
> This is exactly what the validity period is stating: that the warranty is
> valid for a specified time, which is either the validity period of the
> certificate, or another, specified time using the parameters as defined in
> the I-D.  It is presented and offered this way, so there is no need for
> another validity parameter.  If an offeror wanted to specify a time within
> which claims could be made, then a shorter time period than the validity of
> the certificate can be used.  This is unlike the paper-based world in the
> sense that insurance policies are normally of long duration, whereas this
> extension is associated with a certificate that normally has a validity of
> two-three years.
> 
> [Denis] The semantics of the warranty validity period is not defined ! 
> There
> is a need to define more precisely what "the warranty validity period" is.
> Here is a proposal along my original text. If it does not fit, please
> propose an alternative:
> 
> " The warranty validity period is a time period to claim for a compensation
> which must be made X months or Y days after the date of the event which
> created the damage. It is unrelated to the certificate validity period."
> 
> [AS2] What if the warranty validity period is indeed the same as the 
> certificate validity period? This was the scenario assumed to be most 
> likely, as it is stated in s.2.2, and therefore the option was created 
> to allow for a reduction in size of the extension by having NULL in 
> warranty validity period in the case where it was the same as the 
> certificate validity period.  When it is not the same as the certificate 
> validity period, then the parameters available for warranty validity 
> period can be used.
> 
> 6 - The wType offers only two types of warranty: aggregated and per
> transaction.
> 
> "Aggregated" means that that once the value of the fulfilled claims reaches
> the maximum warranty amount, then no further claim will be fulfilled.
> 
> "Per transaction" means that each claim is handled independently but no
> individual claim can exceed the maximum warranty amount.
> 
> Each type has its own problems:
> 
> "Aggregated" is like a race where late claimants will get no 
> compensation at
> all because they were not "fast enough". It is questionable whether such a
> race condition will be acceptable.
> It should be understood that aggregation applies to one warranty and one
> claimant.  This is analogous to the paper-based world.  When you are 
> covered
> by warranty for X product or service, e.g., health insurance, there is 
> often
> an upper limit (viz. the "value") up to which claims will be met for each
> claimant; i.e., one insured person.
> "Per transaction" means that the CA cannot compute the maximum amount of
> money that it may have to give away. Which insurance company will ever
> insure a risk for which an upper limit cannot be computed ?
> 
> [Alice]
> The T&C, as noted in section 1, as covered by insurance, will specify the
> maximum. The type of warranty selected depends on the nature of the
> transactions, the parties to the transactions (e.g., individuals, large
> institutions, etc.).
> 
> [Denis] What I am asking for is to allow a combination of both types, which
> is currently not possible. See below again.
> 
> None of these schemes is acceptable. Some combination should be allowed:
> 
>    - a maximum amount per transaction, and
>    - a maximum amount per certificate with a maximum time period
>      to claim for a compensation after the date of the event
>      (no race problem implied).
> 
> [AS2] You have a good point. We may need some clarification in s.2.2 to 
> explain exactly what the currency amount means.  This is clearly stated 
> (and obvious) with respect to aggregate, but not so with 
> per-transaction.  It should be indicated that there will be a maximum 
> total of per-transaction claims, which would be standard practice, and 
> necessary for the ongoing health of the CA.  The total warranty offered 
> for per-transaction claims could be expressed as a new parameter 
> indicating number of per-transaction claims before the maximum would br 
> reached, which would be simple to calculate since the per-transaction 
> maximum is stated; e.g., a sub-line after the per-transaction type code, 
> number of transactions as a maximum.
> 
> 7 - The content of the security consideration should be augmented to
> indicate the difference between what a computer program can do and a human
> being can do with this extension.
> 
> [Alice]
> I would have thought this to be blindingly obvious.  We would, however, be
> quite willing to consider some proposed words to address this, if you do
> think it is necessary.
> 
> [Denis] If my text proposal related to comment 2 is inserted, then this is
> no more needed.
> 
> [AS2] Still willing to consider a proposal, but as you can see from my 
> response to your comments on point 2, I don't think this is quite right.
> 
> 8 - The document is not mature enough and its added value is still
> questionable.
> 
> [Alice]
> We believe that it is mature.  Its value may be questionable to those 
> who do
> not want to use it, but given that it is (a) proposed as Informational and
> (b) always non-critical, surely its availability for use is innocuous for
> those that do not want to use it.  For those who do want to use it, and we
> have heard from quite a number who do, it will be useful and valuable.  As
> in section 1: "When a certificate contains a warranty certificate 
> extension,
> the extension MUST be non-critical, ..."
> 
> [Denis]
> As you can see, we have progressed, but several issues still need to be
> addressed.
> 
> [AS2] Yes, we have made progress.
> 
> Denis
> 
> 
>> File(s) can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-03.txt
>>
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N3bcI7077322 for <[e-mail]>; Wed, 22 Oct 2003 20:37:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9N3bcNi077321 for ietf-pkix-bks; Wed, 22 Oct 2003 20:37:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N3bYI7077316 for <[e-mail]>; Wed, 22 Oct 2003 20:37:37 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9N3bTRS016084; Thu, 23 Oct 2003 16:37:29 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9N3cap19981; Thu, 23 Oct 2003 16:38:36 +1300
Date: Thu, 23 Oct 2003 16:38:36 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'll reply briefly to several messages at once here to keep the message count
down...

"Stefan Santesson" <[e-mail]> writes:

>If an application use AKI/SKI match to discover a path and finds an AKI/SKI
>match of unrelated keys. What happens? Ignoring what applications SHOULD do
>(which we all know) What is in fact the current behaviour of applications
>today:

I match first on DNs and only if that fails do I fall back to keyIDs (provided
the keyID is > 40 bits, i.e. not a non-unique small integer).  I'm not aware
of the match on DNs ever having failed.  It's one of these things that users
just know about (sort of like "Don't user Master Documents in MS Word" or
"Don't change the monitor frequency settings in XF86Config"), you can either
play it safe and know it'll work or live dangerously but have to expect things
to break.  If you expect things to break anyway then presumably you're
prepared to do the necessary manual tweaking to sort things out.  An easier
option for most people is just to make sure that you never put yourself in a
situation where things can break.

=?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]> writes:

>Or is it just YAPEB [1]?
>
>[1] yet another PKIX extension bloat

In my earlier message I originally had a tongue-in-cheek comment that the
purpose of the keyIDs was for the CA to communicate to a RP that it didn't
consider the certificate bloated enough, but I removed it before I sent the
message.

"Al Arsenault" <[e-mail]> writes:

>So, your assertion is that a bastardized hybrid of a widely-used but non-
>standard protocol (SCEP)

I was waiting for someone to bring that up :-).  I'd considered just putting
in a blank space in place of the term "SCEP" in my post in reference to the
PKIX NIH effect blanking it out.

>with an updated wrapping mechanism (CMS) will cause problems for some types
>of signature validation software, and this is a reason why one option
>permitted by PKIX is a fundamental flaw?

You asked for an example, that's a quick example (the reason SCEP uses PKCS #7
is because that's what Cisco had lying around when they created it.  I'm sure
any even vaguely recent SCEP implementation will be built with a CMS toolkit).
In any case it was just a top-of-my-head example (I'm not going to search
through every case of CMS use to see how many would be affected by this, it's
used in all sorts of weird and wonderful places), the point is that if the
spec allows this behaviour then it's broken.

Jean-Marc Desperrier <[e-mail]> writes:

>Do cross-certifying CA discards all extensions inside the request so that
>it's not possible to specify the SKID by including it as an extension inside
>the request ?

My code copies all extensions across (although the CA app is free to delete
any that it doesn't like).  Feedback from users was that if they didn't want
it in the request they wouldn't be specifying it, and conversely if they did
specify it then they didn't want the CA arbitrarily stripping it out.

All manner of people wrote:

>[ Six angels! / Four angels! / Eight angels! / No angels! / A dachshund! ]

The general response to this issue has been some variation of "Users will get
it right" (= push it onto the users) / "It's a policy issue" (= push it onto
the users) / "It's a local configuration issue" (= push it onto the users).
If the PKI experts can't even agree on how to interpret/handle this, how on
earth can non-technical users be expected to get it right?

I'll conclude with a wonderful quote from someone else (who probably doesn't
want his name mentioned :-).  It's in reference to the UK comedy "Father Ted":

  Ted says that whenever he gets asked a religious question he doesn't
  understand he always responds with "Ah, that must be an ecumenical matter"
  which univerally produces nods of admiration at the profound wisdom of the
  statement. It seems that that the PKIX list equivalent is "Ah that must be a
  policy matter".

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N28LI7074669 for <[e-mail]>; Wed, 22 Oct 2003 19:08:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9N28LnS074668 for ietf-pkix-bks; Wed, 22 Oct 2003 19:08:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from orb.pobox.com (puzzle.pobox.com [207.8.214.3]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N28KI7074663 for <[e-mail]>; Wed, 22 Oct 2003 19:08:20 -0700 (PDT) (envelope-from [e-mail])
Received: from texas.pobox.com (texas.pobox.com[64.49.223.111]) by orb.pobox.com (Postfix) with ESMTP id D45E8CCFAF; Wed, 22 Oct 2003 22:08:22 -0400 (EDT)
Received: from gnosis (12-230-199-189.client.attbi.com [12.230.199.189]) by texas.pobox.com (Postfix) with ESMTP id 96B84453BB; Wed, 22 Oct 2003 22:08:21 -0400 (EDT)
From: "L Williams" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 19:08:15 -0700
Message-ID: <000601c3990a$863a5b80$6601a8c0@gnosis>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Man, I was loving this thread up until this point.

I think what this thread established was that sane CAs should be able to
respect existing key identifiers when they do cross-certification/bridging.
This means that AKI/SKI chaining should work the majority of the time, not
fail the majority of the time. Seems to me that the change would be to make
this a "SHOULD" not a "SHOULD NOT".

Yes, there are backwards compatibility issues, but this can be dealt with.

-Laudon
(Microsoft)

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Steve Hanna
Sent: Wednesday, October 22, 2003 1:59 PM
To: Peter Hesse
Cc: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?

Maybe we are close to ending this discussion. Everyone
agrees that CAs MUST use an SKI in CA certificates that
matches the AKI used in certificates issued by the
subject of the certificate. Relying parties can use
this as a hint during path construction, but they should
not require AKI/SKI matching during path construction or
path validation.

But RFC 3280 does not say clearly and explicitly that
relying parties should not require AKI/SKI matching.
Several implementors have misunderstood this. I suggest
that the successor to RFC 3280 should be changed to
make an explicit recommendation that relying parties
SHOULD NOT require AKI/SKI matching.

Thanks,

Steve

Peter Hesse wrote:
> 
> Santosh,
> 
> Point taken.  3280 therefore requires that the keyIdentifier method (as
> opposed to the issuer DN/serial tuple) MUST be used.  In 4.2.1.1 (AKID)
> it only RECOMMENDS this; but the words you quote from 4.2.1.2 (SKID)
> make it a requirement, intentionally or not.  As you said, in the below
> case, at least one CA is not compliant with 3280.  Unfortunately, I've
> seen this happen in practice.  As you said earlier, it would be best if
> path building implementations could be flexible about this, but
> certificate producers should be compliant.
> 
> Two other things: Sharon is dead on, and the only thing I would say is
> that support for accepting SKIDs in certification requests seems to work
> well with a particular implementation, but require manual input or is
> not possible between different implementations.
> 
> And Jean-Marc was also quite correct, my example was wrong.  It's the
> Issuer's Issuer DN and serial, I just put the Issuer's DN in my example.
> Shame on me.
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    [e-mail]     |
> | Phone: [phone]         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been
> a statue set up in honor of a critic." --Jean Sibelius
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: Wednesday, October 22, 2003 2:01 PM
> To: [e-mail]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> Peter:
> 
> Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote:
> "The value of the subject key identifier MUST be the value placed in the
> key identifier field of the Authority Key Identifier extension (section
> 4.2.1.1) of certificates issued by the subject of this certificate."
> Read in context, the above is stated for CA certificates.
> 
> Thus, in cross certified environment, 3280 compliant issuing CAs need to
> ensure that the SKI in 3280 compliant subject CA certificate is the
> value that the subject CA intends to use as AKI for certificates it
> issues.
> 
> If the AKI and SKI (even for cross certified environments) do not chain,
> one or more of the CAs is not compliant with 3280.
> 
> -----Original Message-----
> From: Peter Hesse [mailto:[e-mail]]
> Sent: Wednesday, October 22, 2003 12:59 PM
> To: 'Santosh Chokhani'; [e-mail]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> Santosh Chokhani wrote:
> > My e-mail needs to be read in the context of the producers. The CAs as
> 
> > producers need to ensure that the AKI and SKI chain. If the CAs do not
> 
> > do that, they are not compliant with 3280.
> > That means in order to comply with 3280 issuing CA needs to
> > honor the SKID requested by the subject CAs.
> 
> I think we're in violent agreement.  My main point was that although the
> producer needs to ensure that AKID and SKID chain, cross-PKI
> interoperability will cause cases in which the producer must choose
> between two (or more) equally valid AKIDs to place in a subject
> certificate.  Either of them will chain successfully and the producer
> will be compliant; but as a result there will be valid paths where the
> AKID and SKID will not chain, through no fault of the producer.
> 
> --Peter



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MNJDI7066907 for <[e-mail]>; Wed, 22 Oct 2003 16:19:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MNJCEV066906 for ietf-pkix-bks; Wed, 22 Oct 2003 16:19:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MNJBI7066896 for <[e-mail]>; Wed, 22 Oct 2003 16:19:12 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (39.arlington-13-14rs.va.dial-access.att.net[12.92.101.39]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003102223190511100hcejoe>; Wed, 22 Oct 2003 23:19:05 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 19:19:03 -0400
Message-ID: <000001c398f2$e33fc260$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9MNJCI7066902
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sharon:

I agree.  What you listed is the simplest way to meet the requirement.

-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]] 
Sent: Wednesday, October 22, 2003 3:46 PM
To: 'Peter Hesse'; 'Santosh Chokhani'; [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?


Now I'm getting confused???

To simplify the discussion....

Shouldn't a CA determine what its own key identifier is (and 3280 recommends
ways to calulate it). One they have their own key id, this value should  
go into the AKI extension of all certificates issued by that CA and should
go 
into the SKI extension of all certificates issued to that CA. When acting 
as the issuer, the CA knows the value and simply populates it. When acting
as 
the subject, the CA should pass the value in the certificate request it
sends 
to the issuing CA and that value should be used by the issuing CA to
populate 
the SKI. If the value is not sent in the cert request, then the issuer CA
needs 
to use other means to determine the correct value for that SKI.


-----Original Message-----
From: Peter Hesse [mailto:[e-mail]]
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?



Santosh Chokhani wrote:
> My e-mail needs to be read in the context of the producers.
> The CAs as producers need to ensure that the AKI and SKI chain.
> If the CAs do not do that, they are not compliant with 3280.  
> That means in order to comply with 3280 issuing CA needs to 
> honor the SKID requested by the subject CAs.

I think we're in violent agreement.  My main point was that although the
producer needs to ensure that AKID and SKID chain, cross-PKI
interoperability will cause cases in which the producer must choose between
two (or more) equally valid AKIDs to place in a subject certificate.  Either
of them will chain successfully and the producer will be compliant; but as a
result there will be valid paths where the AKID and SKID will not chain,
through no fault of the producer.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MMS6I7065227 for <[e-mail]>; Wed, 22 Oct 2003 15:28:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MMS6fO065226 for ietf-pkix-bks; Wed, 22 Oct 2003 15:28:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [212.157.154.44]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MMS4I7065219 for <[e-mail]>; Wed, 22 Oct 2003 15:28:04 -0700 (PDT) (envelope-from [e-mail])
Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 23 Oct 2003 00:27:59 +0200
Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Oct 2003 00:27:59 +0200
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 23 Oct 2003 00:27:59 +0200
x-mimeole: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 23:27:57 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AKI and SKI problem with RFC 3280?
Thread-Index: AcOY6sPhOZzpnx66QEKec+4se7t/twAAEsgw
From: "Stefan Santesson" <[e-mail]>
To: "Steve Hanna" <[e-mail]>, "Peter Hesse" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 22 Oct 2003 22:27:59.0197 (UTC) FILETIME=[BF5FD0D0:01C398EB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9MMS5I7065222
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Agree,

And may I also suggest limiting recommendations to key identifiers
derived from the key hash, unless there is a strong need for other
solutions not yet presented in this debate.

/Stefan

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Steve Hanna
> Sent: den 22 oktober 2003 22:59
> To: Peter Hesse
> Cc: [e-mail]
> Subject: Re: AKI and SKI problem with RFC 3280?
> 
> Maybe we are close to ending this discussion. Everyone
> agrees that CAs MUST use an SKI in CA certificates that
> matches the AKI used in certificates issued by the
> subject of the certificate. Relying parties can use
> this as a hint during path construction, but they should
> not require AKI/SKI matching during path construction or
> path validation.
> 
> But RFC 3280 does not say clearly and explicitly that
> relying parties should not require AKI/SKI matching.
> Several implementors have misunderstood this. I suggest
> that the successor to RFC 3280 should be changed to
> make an explicit recommendation that relying parties
> SHOULD NOT require AKI/SKI matching.
> 
> Thanks,
> 
> Steve
> 
> Peter Hesse wrote:
> >
> > Santosh,
> >
> > Point taken.  3280 therefore requires that the keyIdentifier method
(as
> > opposed to the issuer DN/serial tuple) MUST be used.  In 4.2.1.1
(AKID)
> > it only RECOMMENDS this; but the words you quote from 4.2.1.2 (SKID)
> > make it a requirement, intentionally or not.  As you said, in the
below
> > case, at least one CA is not compliant with 3280.  Unfortunately,
I've
> > seen this happen in practice.  As you said earlier, it would be best
if
> > path building implementations could be flexible about this, but
> > certificate producers should be compliant.
> >
> > Two other things: Sharon is dead on, and the only thing I would say
is
> > that support for accepting SKIDs in certification requests seems to
work
> > well with a particular implementation, but require manual input or
is
> > not possible between different implementations.
> >
> > And Jean-Marc was also quite correct, my example was wrong.  It's
the
> > Issuer's Issuer DN and serial, I just put the Issuer's DN in my
example.
> > Shame on me.
> >
> > --Peter
> >
> > +---------------------------------------------------------------+
> > | Peter Hesse                    [e-mail]     |
> > | Phone: [phone]         Gemini Security Solutions, Inc.  |
> > | ICQ: 1942828                     www.geminisecurity.com       |
> > +---------------------------------------------------------------+
> > "Pay no attention to what the critics say; there has never been
> > a statue set up in honor of a critic." --Jean Sibelius
> >
> > -----Original Message-----
> > From: [e-mail]
[mailto:[e-mail]]
> > On Behalf Of Santosh Chokhani
> > Sent: Wednesday, October 22, 2003 2:01 PM
> > To: [e-mail]
> > Subject: RE: AKI and SKI problem with RFC 3280?
> >
> > Peter:
> >
> > Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote:
> > "The value of the subject key identifier MUST be the value placed in
the
> > key identifier field of the Authority Key Identifier extension
(section
> > 4.2.1.1) of certificates issued by the subject of this certificate."
> > Read in context, the above is stated for CA certificates.
> >
> > Thus, in cross certified environment, 3280 compliant issuing CAs
need to
> > ensure that the SKI in 3280 compliant subject CA certificate is the
> > value that the subject CA intends to use as AKI for certificates it
> > issues.
> >
> > If the AKI and SKI (even for cross certified environments) do not
chain,
> > one or more of the CAs is not compliant with 3280.
> >
> > -----Original Message-----
> > From: Peter Hesse [mailto:[e-mail]]
> > Sent: Wednesday, October 22, 2003 12:59 PM
> > To: 'Santosh Chokhani'; [e-mail]
> > Subject: RE: AKI and SKI problem with RFC 3280?
> >
> > Santosh Chokhani wrote:
> > > My e-mail needs to be read in the context of the producers. The
CAs as
> >
> > > producers need to ensure that the AKI and SKI chain. If the CAs do
not
> >
> > > do that, they are not compliant with 3280.
> > > That means in order to comply with 3280 issuing CA needs to
> > > honor the SKID requested by the subject CAs.
> >
> > I think we're in violent agreement.  My main point was that although
the
> > producer needs to ensure that AKID and SKID chain, cross-PKI
> > interoperability will cause cases in which the producer must choose
> > between two (or more) equally valid AKIDs to place in a subject
> > certificate.  Either of them will chain successfully and the
producer
> > will be compliant; but as a result there will be valid paths where
the
> > AKID and SKID will not chain, through no fault of the producer.
> >
> > --Peter



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKxYI7062029 for <[e-mail]>; Wed, 22 Oct 2003 13:59:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MKxYs7062028 for ietf-pkix-bks; Wed, 22 Oct 2003 13:59:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKxXI7062020 for <[e-mail]>; Wed, 22 Oct 2003 13:59:33 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9MKxSUP023610; Wed, 22 Oct 2003 13:59:29 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h9MKxSB12085; Wed, 22 Oct 2003 16:59:28 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 22 Oct 2003 16:58:57 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Hesse <[e-mail]>
CC: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <010b01c398d8$d8a5faa0$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1A4950776C601A796E2B43DF"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms1A4950776C601A796E2B43DF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Maybe we are close to ending this discussion. Everyone
agrees that CAs MUST use an SKI in CA certificates that
matches the AKI used in certificates issued by the
subject of the certificate. Relying parties can use
this as a hint during path construction, but they should
not require AKI/SKI matching during path construction or
path validation.

But RFC 3280 does not say clearly and explicitly that
relying parties should not require AKI/SKI matching.
Several implementors have misunderstood this. I suggest
that the successor to RFC 3280 should be changed to
make an explicit recommendation that relying parties
SHOULD NOT require AKI/SKI matching.

Thanks,

Steve

Peter Hesse wrote:
> 
> Santosh,
> 
> Point taken.  3280 therefore requires that the keyIdentifier method (as
> opposed to the issuer DN/serial tuple) MUST be used.  In 4.2.1.1 (AKID)
> it only RECOMMENDS this; but the words you quote from 4.2.1.2 (SKID)
> make it a requirement, intentionally or not.  As you said, in the below
> case, at least one CA is not compliant with 3280.  Unfortunately, I've
> seen this happen in practice.  As you said earlier, it would be best if
> path building implementations could be flexible about this, but
> certificate producers should be compliant.
> 
> Two other things: Sharon is dead on, and the only thing I would say is
> that support for accepting SKIDs in certification requests seems to work
> well with a particular implementation, but require manual input or is
> not possible between different implementations.
> 
> And Jean-Marc was also quite correct, my example was wrong.  It's the
> Issuer's Issuer DN and serial, I just put the Issuer's DN in my example.
> Shame on me.
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    [e-mail]     |
> | Phone: [phone]         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been
> a statue set up in honor of a critic." --Jean Sibelius
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: Wednesday, October 22, 2003 2:01 PM
> To: [e-mail]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> Peter:
> 
> Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote:
> "The value of the subject key identifier MUST be the value placed in the
> key identifier field of the Authority Key Identifier extension (section
> 4.2.1.1) of certificates issued by the subject of this certificate."
> Read in context, the above is stated for CA certificates.
> 
> Thus, in cross certified environment, 3280 compliant issuing CAs need to
> ensure that the SKI in 3280 compliant subject CA certificate is the
> value that the subject CA intends to use as AKI for certificates it
> issues.
> 
> If the AKI and SKI (even for cross certified environments) do not chain,
> one or more of the CAs is not compliant with 3280.
> 
> -----Original Message-----
> From: Peter Hesse [mailto:[e-mail]]
> Sent: Wednesday, October 22, 2003 12:59 PM
> To: 'Santosh Chokhani'; [e-mail]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> Santosh Chokhani wrote:
> > My e-mail needs to be read in the context of the producers. The CAs as
> 
> > producers need to ensure that the AKI and SKI chain. If the CAs do not
> 
> > do that, they are not compliant with 3280.
> > That means in order to comply with 3280 issuing CA needs to
> > honor the SKID requested by the subject CAs.
> 
> I think we're in violent agreement.  My main point was that although the
> producer needs to ensure that AKID and SKID chain, cross-PKI
> interoperability will cause cases in which the producer must choose
> between two (or more) equally valid AKIDs to place in a subject
> certificate.  Either of them will chain successfully and the producer
> will be compliant; but as a result there will be valid paths where the
> AKID and SKID will not chain, through no fault of the producer.
> 
> --Peter
--------------ms1A4950776C601A796E2B43DF
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMxMDIyMjA1ODU3WjAjBgkqhkiG9w0BCQQxFgQUDsK5P5VceEdaXsvUVNSLMyDE
GugwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAcwMee
kgTTPRSFTGkc5ZN0ZXqkCyebi1WVE/rirqh34a0tMiol/OY75HMH0GOs8RojefDOuQMK4scA
0jOz5fVmA/eUKzpCrlrn/WbM8MWuFX6VyQRtRuar6RBK5lzWeNmnADRz8qg7N112UAkKdzEF
vdDfgmPgp26vlHvdZ0+Rbw==
--------------ms1A4950776C601A796E2B43DF--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKUmI7060794 for <[e-mail]>; Wed, 22 Oct 2003 13:30:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MKUmed060793 for ietf-pkix-bks; Wed, 22 Oct 2003 13:30:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKUkI7060787 for <[e-mail]>; Wed, 22 Oct 2003 13:30:47 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd07.aul.t-online.de  by mailout10.sul.t-online.com with smtp  id 1ACPcp-0006Xo-02; Wed, 22 Oct 2003 22:30:35 +0200
Received: from hagen (SyZwC6ZQgeZYSTHRvvacdQ5czZbvf20gG2XJIfB82IVL2J6CN5E9gM@[217.80.254.199]) by fmrl07.sul.t-online.com with esmtp id 1ACPci-0eFSpk0; Wed, 22 Oct 2003 22:30:28 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>, "'Michael Myers'" <[e-mail]>
Cc: "'David Engberg'" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Wed, 22 Oct 2003 22:30:26 +0200
Organization: SyTrust
Message-ID: <000001c398db$54ab0620$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [...] The options were original (with unclear 
> semantics in this respect), nonce required in response, and 
> nonce optional in response.
> For a server to actually prevent misunderstandings of 
> whether or not he supports nonces by using a unilateral
> server-side extension, you'd need a server-side 
> extension called "nonceSupported" with boolean syntax, 
> which would have to be placed in EVERY response whether 
> nonces are present in the request or not.

Client side extension:
Good idea. I certainly support such an extension. One thing we should
keep in mind: currently ALL extensions in OCSP are OPTIONAL. We have to
make sure that the RfC does not contradict itself.

I fully support your server-side extension. Simple and good. I like it.

Both good ideas - lets go with them :)

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKDpI7059970 for <[e-mail]>; Wed, 22 Oct 2003 13:13:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MKDprs059969 for ietf-pkix-bks; Wed, 22 Oct 2003 13:13:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKDnI7059959 for <[e-mail]>; Wed, 22 Oct 2003 13:13:49 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id QAA480931 for <[e-mail]>; Wed, 22 Oct 2003 16:13:50 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 16:12:40 -0400
Organization: Gemini Security Solutions, Inc.
Message-ID: <010b01c398d8$d8a5faa0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <004a01c398c6$854230c0$[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

Point taken.  3280 therefore requires that the keyIdentifier method (as
opposed to the issuer DN/serial tuple) MUST be used.  In 4.2.1.1 (AKID)
it only RECOMMENDS this; but the words you quote from 4.2.1.2 (SKID)
make it a requirement, intentionally or not.  As you said, in the below
case, at least one CA is not compliant with 3280.  Unfortunately, I've
seen this happen in practice.  As you said earlier, it would be best if
path building implementations could be flexible about this, but
certificate producers should be compliant.

Two other things: Sharon is dead on, and the only thing I would say is
that support for accepting SKIDs in certification requests seems to work
well with a particular implementation, but require manual input or is
not possible between different implementations.

And Jean-Marc was also quite correct, my example was wrong.  It's the
Issuer's Issuer DN and serial, I just put the Issuer's DN in my example.
Shame on me.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, October 22, 2003 2:01 PM
To: [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?



Peter:

Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote:
"The value of the subject key identifier MUST be the value placed in the
key identifier field of the Authority Key Identifier extension (section
4.2.1.1) of certificates issued by the subject of this certificate."
Read in context, the above is stated for CA certificates.

Thus, in cross certified environment, 3280 compliant issuing CAs need to
ensure that the SKI in 3280 compliant subject CA certificate is the
value that the subject CA intends to use as AKI for certificates it
issues.

If the AKI and SKI (even for cross certified environments) do not chain,
one or more of the CAs is not compliant with 3280.

-----Original Message-----
From: Peter Hesse [mailto:[e-mail]] 
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?


Santosh Chokhani wrote:
> My e-mail needs to be read in the context of the producers. The CAs as

> producers need to ensure that the AKI and SKI chain. If the CAs do not

> do that, they are not compliant with 3280.
> That means in order to comply with 3280 issuing CA needs to 
> honor the SKID requested by the subject CAs.

I think we're in violent agreement.  My main point was that although the
producer needs to ensure that AKID and SKID chain, cross-PKI
interoperability will cause cases in which the producer must choose
between two (or more) equally valid AKIDs to place in a subject
certificate.  Either of them will chain successfully and the producer
will be compliant; but as a result there will be valid paths where the
AKID and SKID will not chain, through no fault of the producer.

--Peter



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MJk3I7058671 for <[e-mail]>; Wed, 22 Oct 2003 12:46:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MJk3fU058670 for ietf-pkix-bks; Wed, 22 Oct 2003 12:46:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MJjwI7058660 for <[e-mail]>; Wed, 22 Oct 2003 12:46:01 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.8/Switch-2.2.4) with SMTP id V9MJ2AGY0000133C for <[e-mail]>; Wed, 22 Oct 2003 15:46:16 -0400
Received: (qmail 17276 invoked by uid 111); 22 Oct 2003 23:34:58 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-2.1.0 (Processed in 3.532859 secs); 22 Oct 2003 23:34:58 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 22 Oct 2003 23:34:54 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <VM0GX69Z>; Wed, 22 Oct 2003 15:45:47 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Peter Hesse'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 15:45:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Now I'm getting confused???

To simplify the discussion....

Shouldn't a CA determine what its own key identifier is (and 3280 recommends
ways to calulate it). One they have their own key id, this value should  
go into the AKI extension of all certificates issued by that CA and should
go 
into the SKI extension of all certificates issued to that CA. When acting 
as the issuer, the CA knows the value and simply populates it. When acting
as 
the subject, the CA should pass the value in the certificate request it
sends 
to the issuing CA and that value should be used by the issuing CA to
populate 
the SKI. If the value is not sent in the cert request, then the issuer CA
needs 
to use other means to determine the correct value for that SKI.


-----Original Message-----
From: Peter Hesse [mailto:[e-mail]]
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?



Santosh Chokhani wrote:
> My e-mail needs to be read in the context of the producers.  
> The CAs as producers need to ensure that the AKI and SKI chain.
> If the CAs do not do that, they are not compliant with 3280.  
> That means in order to comply with 3280 issuing CA needs to 
> honor the SKID requested by the subject CAs.

I think we're in violent agreement.  My main point was that although the
producer needs to ensure that AKID and SKID chain, cross-PKI
interoperability will cause cases in which the producer must choose
between two (or more) equally valid AKIDs to place in a subject
certificate.  Either of them will chain successfully and the producer
will be compliant; but as a result there will be valid paths where the
AKID and SKID will not chain, through no fault of the producer.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MI1cI7053828 for <[e-mail]>; Wed, 22 Oct 2003 11:01:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MI1caK053827 for ietf-pkix-bks; Wed, 22 Oct 2003 11:01:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MI1bI7053822 for <[e-mail]>; Wed, 22 Oct 2003 11:01:37 -0700 (PDT) (envelope-from [e-mail])
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by mclean-vscan1.bah.com (8.11.0/8.11.0) with SMTP id h9MI1Ve28502 for <[e-mail]>; Wed, 22 Oct 2003 14:01:32 -0400 (EDT)
Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan1.bah.com (NAVGW 2.5.2.12) with SMTP id M2003102214013128548 for <[e-mail]>; Wed, 22 Oct 2003 14:01:31 -0400
Received: from wchokhani ([156.80.127.166]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HN67EJ00.TQS for <[e-mail]>; Wed, 22 Oct 2003 14:01:31 -0400 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 14:01:29 -0400
Message-ID: <004a01c398c6$854230c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <00c901c398bd$d96176b0$[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9MI1bI7053823
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote: "The
value of the subject key identifier MUST be the value placed in the key
identifier field of the Authority Key Identifier extension (section 4.2.1.1)
of certificates issued by the subject of this certificate."  Read in
context, the above is stated for CA certificates.

Thus, in cross certified environment, 3280 compliant issuing CAs need to
ensure that the SKI in 3280 compliant subject CA certificate is the value
that the subject CA intends to use as AKI for certificates it issues.

If the AKI and SKI (even for cross certified environments) do not chain, one
or more of the CAs is not compliant with 3280.

-----Original Message-----
From: Peter Hesse [mailto:[e-mail]] 
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?


Santosh Chokhani wrote:
> My e-mail needs to be read in the context of the producers.
> The CAs as producers need to ensure that the AKI and SKI chain.
> If the CAs do not do that, they are not compliant with 3280.  
> That means in order to comply with 3280 issuing CA needs to 
> honor the SKID requested by the subject CAs.

I think we're in violent agreement.  My main point was that although the
producer needs to ensure that AKID and SKID chain, cross-PKI
interoperability will cause cases in which the producer must choose between
two (or more) equally valid AKIDs to place in a subject certificate.  Either
of them will chain successfully and the producer will be compliant; but as a
result there will be valid paths where the AKID and SKID will not chain,
through no fault of the producer.

--Peter




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MHAuI7051560 for <[e-mail]>; Wed, 22 Oct 2003 10:10:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MHAuKE051559 for ietf-pkix-bks; Wed, 22 Oct 2003 10:10:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MHAsI7051552 for <[e-mail]>; Wed, 22 Oct 2003 10:10:55 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft4.fr.colt.net with ESMTP id h9MHAsH17810 for <[e-mail]>; Wed, 22 Oct 2003 19:10:54 +0200
Message-ID: <[e-mail]>
Date: Wed, 22 Oct 2003 19:11:34 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031004
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <003501c398a1$d0c0d1c0$[e-mail]>
In-Reply-To: <003501c398a1$d0c0d1c0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Hesse wrote:

>+------------------+                +--------------------+
>|  Allied Pilots   |                |     Boeing Root    |
>| Association Root |                |                    |
>|                  |                | SKID: Q            |
>| SKID: A          |                |                    |
>+------------------+                +--------------------+
>         \                                   /
>          \                                 /
>           V                               V
>    =================================================
>    | +-------------------+   +-------------------+ |
>    | | American Airlines |   | American Airlines | |
>    | |                   |   |                   | |
>    | | SN: 12345         |   | SN: 87654         | |
>    | | SKID: Z           |   | SKID: Z           | |
>    | | AKID: A           |   | AKID: Q           | |
>    | +-------------------+   +-------------------+ |
>    =================================================
>                            |
>                            |
>                            V
>                  +-------------------+
>                  |     Joe Pilot     |
>                  |                   |
>                  | SKID: W           |
>                  | AKID: "American   |
>                  |        Airlines,  |
>                  |        12345"     |
>                  +-------------------+
>  
>
This AKID is wrong. It should be "Allied Pilots Association Root, 12345".
This type of AKID is a issuer name/serial pair, this means pointing 
amongst the certificate emitted by ca IssuerName to the one that has the 
serial SN.
American Airlines certificate is the certificate SN:12345 amongst those 
issued by "Allied Pilots Association Root"

You certainly know about this, but this particular misinterpretation of 
AKID tends to be a recurrent problem, so I feel better not to leave it 
uncorrected.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MH8uI7051468 for <[e-mail]>; Wed, 22 Oct 2003 10:08:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MH8uMh051467 for ietf-pkix-bks; Wed, 22 Oct 2003 10:08:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MH8sI7051460 for <[e-mail]>; Wed, 22 Oct 2003 10:08:55 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft6.fr.colt.net with ESMTP id h9MH8r426018 for <[e-mail]>; Wed, 22 Oct 2003 19:08:54 +0200
Message-ID: <[e-mail]>
Date: Wed, 22 Oct 2003 19:09:33 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031004
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <003501c398a1$d0c0d1c0$[e-mail]>
In-Reply-To: <003501c398a1$d0c0d1c0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Hesse wrote:

>Currently, there is no commonly accepted way to for a
>cross-certifying CA to accept the desired SKID in a request for
>cross-certification.
>
Why ?
Do cross-certifying CA discards all extensions inside the request so 
that it's not possible to specify the SKID by including it as an 
extension inside the request ?
But even when they do, then you need to specify all extensions to 
include by hand, so you could insert the correct SKID transported out of 
band, with the other info needed for that CA, wouldn't you ?

It would be interesting if I'm proven wrong, but it's seems to me 
cross-certifying doesn't happen everyday, and always involves some 
manual operations, so is there really a good reason why you can not do 
this customisation of the parameters ?

I just found a document from the pkiforum that endorses this method : 
http://www.pkiforum.org/pdfs/AKID_SKID1-af3.pdf
It also reports that both U.S. Federal Bridge CA and CESG 
interoperability initiatives reported mismatches preventing proper 
certification path construction.







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MH0YI7051041 for <[e-mail]>; Wed, 22 Oct 2003 10:00:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MH0YbD051040 for ietf-pkix-bks; Wed, 22 Oct 2003 10:00:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MH0WI7051033 for <[e-mail]>; Wed, 22 Oct 2003 10:00:32 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id NAA403008; Wed, 22 Oct 2003 13:00:32 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 12:59:24 -0400
Organization: Gemini Security Solutions, Inc.
Message-ID: <00c901c398bd$d96176b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <003901c398ad$74568fe0$[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh Chokhani wrote:
> My e-mail needs to be read in the context of the producers.  
> The CAs as producers need to ensure that the AKI and SKI chain.
> If the CAs do not do that, they are not compliant with 3280.  
> That means in order to comply with 3280 issuing CA needs to 
> honor the SKID requested by the subject CAs.

I think we're in violent agreement.  My main point was that although the
producer needs to ensure that AKID and SKID chain, cross-PKI
interoperability will cause cases in which the producer must choose
between two (or more) equally valid AKIDs to place in a subject
certificate.  Either of them will chain successfully and the producer
will be compliant; but as a result there will be valid paths where the
AKID and SKID will not chain, through no fault of the producer.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGxtI7051011 for <[e-mail]>; Wed, 22 Oct 2003 09:59:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MGxtQr051010 for ietf-pkix-bks; Wed, 22 Oct 2003 09:59:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGxsI7051005 for <[e-mail]>; Wed, 22 Oct 2003 09:59:54 -0700 (PDT) (envelope-from [e-mail])
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id h9MGxsSf029119; Wed, 22 Oct 2003 12:59:55 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <VJP1NRQS>; Wed, 22 Oct 2003 12:59:54 -0400
Message-ID: <[e-mail]>
From: "Aisenberg, Michael" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: The value of qualified certificates
Date: Wed, 22 Oct 2003 12:59:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As with any other corporate finance discussion, "valuation" is very
subjective and context- and purpose-driven. Having said that, one credible
indicator of valuation is the limit of any indemnification provided by the
certificate issuer.


 -----Original Message-----
From: 	Anders Rundgren
Sent:	Wed Oct 22 08:46:20 2003
To:	[e-mail]
Subject:	The value of qualified certificates


I'm wondering what the value of qualified certificates is,
when e-governments in country after country, buy certificates
from commercial CAs where each CA (or CA network) requires
a business contract with each RP.  As these contracts regulate
liabilities etc. it seems that the legal implications of qualified
certificates become limited or are eliminated.  What's left seems
to only be a certificate profile. I.e. a "format".  Among many such.

Just my 2 (EU) cents

Anders R


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGkfI7050304 for <[e-mail]>; Wed, 22 Oct 2003 09:46:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MGkfkH050303 for ietf-pkix-bks; Wed, 22 Oct 2003 09:46:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGkdI7050298 for <[e-mail]>; Wed, 22 Oct 2003 09:46:39 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h9MGk7H96063; Wed, 22 Oct 2003 09:46:07 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: "David Engberg" <[e-mail]>, <[e-mail]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Wed, 22 Oct 2003 09:49:04 -0700
Message-ID: <[e-mail]>
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)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

Your proposal certainly provides an opportunity for compromise.
But I think we first need to see what emerges from Minneapolis.

Mike

> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Wednesday, October 22, 2003 9:19 AM
> To: Michael Myers
> Cc: David Engberg; [e-mail]
> Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
>
>
>         Michael:
>
>         Does your skepticism about the usefulness of
> unilateral
> server-side extensions mean that we should permit a
> variant of nonce in
> which the client specifies how strongly he needs a
> nonce?  Since the
> current syntax of nonce is not officially published,
> I posted a possible
> extension several weeks ago.  The options were
> original (with unclear
> semantics in this respect), nonce required in
> response, and nonce optional
> in response.
>         For a server to actually prevent
> misunderstandings of whether or
> not he supports nonces by using a unilateral
> server-side extension, you'd
> need a server-side extension called "nonceSupported"
> with boolean syntax,
> which would have to be placed in EVERY response
> whether nonces are present
> in the request or not.  The "nonceUnsupported"
> extension strikes me as
> less useful than that.
>
>                 Tom Gindin
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGJhI7049424 for <[e-mail]>; Wed, 22 Oct 2003 09:19:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MGJhUM049423 for ietf-pkix-bks; Wed, 22 Oct 2003 09:19:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGJfI7049417 for <[e-mail]>; Wed, 22 Oct 2003 09:19:41 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9MGJQXn451594; Wed, 22 Oct 2003 12:19:26 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9MGJMZK061474; Wed, 22 Oct 2003 12:19:23 -0400
To: "Michael Myers" <[e-mail]>
Cc: "David Engberg" <[e-mail]>, [e-mail]
MIME-Version: 1.0
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 22 Oct 2003 12:19:20 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 V602CF2_HF2+ JCHN5R2GH7 JCHN5N2GS6 SSPW5RFPX6 JBUD5N6S4G |September 18, 2003) at 10/22/2003 12:19:25, Serialize complete at 10/22/2003 12:19:25
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Michael:

        Does your skepticism about the usefulness of unilateral 
server-side extensions mean that we should permit a variant of nonce in 
which the client specifies how strongly he needs a nonce?  Since the 
current syntax of nonce is not officially published, I posted a possible 
extension several weeks ago.  The options were original (with unclear 
semantics in this respect), nonce required in response, and nonce optional 
in response.
        For a server to actually prevent misunderstandings of whether or 
not he supports nonces by using a unilateral server-side extension, you'd 
need a server-side extension called "nonceSupported" with boolean syntax, 
which would have to be placed in EVERY response whether nonces are present 
in the request or not.  The "nonceUnsupported" extension strikes me as 
less useful than that.

                Tom Gindin





"Michael Myers" <[e-mail]>
Sent by: [e-mail]
10/18/2003 09:14 PM

 
        To:     "David Engberg" <[e-mail]>
        cc:     <[e-mail]>
        Subject:        RE: DISCUSSION: Nonce-specific error code for OCSP




Dave,

A few thoughts embedded below.

Mike

> -----Original Message-----
> From: David Engberg
>
> . . .
>
> An existing client can't tell the difference between a
> server that doesn't support nonces and a replay
> attack by an attacker who made a nonceless request.
> An explicit "nonceUnsupported" extension in the signed
> body of the response allows a client to securely tell the
> difference between these cases.


The requirement is to bind a request to its associated response
and thus enable relying parties to mitigate replay risks.  I
remain curious to an understanding of how unilateral server-side
response extensions achieve this effect.


> OCSP and other PKIX standards currently allow some
> policy decisions to be made by the infrastructure
> authorities (CAs, responders) and others by the
> relying parties.  For example, the pkix-nocheck
> extension allows the infrastructure to tell clients
> that they should accept a delegated responder cert
> without performing validation.  This extension was
> approved, even though someone could have made an
> argument that "only clients should be allowed to
> set responder validation policies."


In the instance of explicit delegation from a certification
authority, there then exists a business entity which places
itself in a position of risk against damage claims.  Are you
suggesting that an OCSP responder's unilateral inclusion of a
technical artifact is an assertion of willingness to absorb such
risks?

Bear in mind that the relying party problem is notoriously
difficult.  It only appears in the heterogeneous context we are
now debating; else contracts suffice.  If you are unfamiliar
with the issue, you may wish to consult with our legal peers in
the American Bar Association's Information Security Committee.


> Something like "nonceUnsupported" would fall in the
> same category ... the infrastructure is telling
> interested clients about the security characteristics
> of that PK infrastructure and suggesting a security
> policy based on that information.


Infrastructure should serve the needs of its participants rather
than the other way around.

Mike
[phone]







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MF2mI7045445 for <[e-mail]>; Wed, 22 Oct 2003 08:02:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MF2lN7045444 for ietf-pkix-bks; Wed, 22 Oct 2003 08:02:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MF2kI7045439 for <[e-mail]>; Wed, 22 Oct 2003 08:02:47 -0700 (PDT) (envelope-from [e-mail])
Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by mclean-vscan2.bah.com (8.11.0/8.11.0) with SMTP id h9MF2I316447 for <[e-mail]>; Wed, 22 Oct 2003 11:02:18 -0400 (EDT)
Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan2.bah.com (NAVGW 2.5.2.12) with SMTP id M2003102211020506288 for <[e-mail]>; Wed, 22 Oct 2003 11:02:05 -0400
Received: from wchokhani ([156.80.127.166]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HN5Z3H00.PER for <[e-mail]>; Wed, 22 Oct 2003 11:02:05 -0400 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 11:02:04 -0400
Message-ID: <003901c398ad$74568fe0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <003501c398a1$d0c0d1c0$[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9MF2lI7045440
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

My e-mail needs to be read in the context of the producers.  The CAs as
producers need to ensure that the AKI and SKI chain.  If the CAs do not do
that, they are not compliant with 3280.  That means in order to comply with
3280 issuing CA needs to honor the SKID requested by the subject CAs.

The consumers, i.e., the relying parties should not enforce the AKI and SKI
chaining.  They can use the match as the prioritization during path
construction.

Forcing CAs to enforce the AKI and SKI match and not requiring the relying
parties to enforce it (but simply use as a prioritization) offers us the
best of both worlds in terms of enhancing interoperability.

As for algorithm for constructing the values, 3280 should and does provides
these as recommendations as opposed to SHALL or MUST.

-----Original Message-----
From: Peter Hesse [mailto:[e-mail]] 
Sent: Wednesday, October 22, 2003 9:39 AM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?


Santosh,

> Based on a review of Sections 4.2.1.2 and 4.2.1.1 of
> 3280, I draw the following conclusion: A 3280 compliant
> CA MUST ensure that AKI and SKI chain properly.  This
> is sufficient for path construction.  Thus, I do not 
> see a particular need to change 3280 in this area.

I read this differently.  I agree that for a given CA, that CA must make
sure that for certificates it issues, the AKID and SKID must match. However,
when you add the "IssuerDN/Serial" tuple version of AKID, that can no longer
be true.  When you start interoperating across domains, there are times at
which AKID and SKID will not match, but yet it should lead to a valid path.
Consider the following example:

+------------------+                +--------------------+
|  Allied Pilots   |                |     Boeing Root    |
| Association Root |                |                    |
|                  |                | SKID: Q            |
| SKID: A          |                |                    |
+------------------+                +--------------------+
         \                                   /
          \                                 /
           V                               V
    =================================================
    | +-------------------+   +-------------------+ |
    | | American Airlines |   | American Airlines | |
    | |                   |   |                   | |
    | | SN: 12345         |   | SN: 87654         | |
    | | SKID: Z           |   | SKID: Z           | |
    | | AKID: A           |   | AKID: Q           | |
    | +-------------------+   +-------------------+ |
    =================================================
                            |
                            |
                            V
                  +-------------------+
                  |     Joe Pilot     |
                  |                   |
                  | SKID: W           |
                  | AKID: "American   |
                  |        Airlines,  |
                  |        12345"     |
                  +-------------------+

In our example, we have the "American Airlines" entity which has two
certificates, one issued by the Allied Pilots Association (AA's union) and
the other by Boeing (one of their manufacturers).  These two certificates
have the same public key and subject public key identifier, but different
serial numbers.  "American Airlines" issues a certificate to "Joe Pilot".
Although Joe Pilot's AKID points to the AA Root certificate issued by the
Allied Pilots Association, there is no reason why a path to the Boeing Root
should not be found equally acceptable.

The other thing at play was what Steve Hanna mentioned in an earlier
message.  Currently, there is no commonly accepted way to for a
cross-certifying CA to accept the desired SKID in a request for
cross-certification.  Therefore, many CAs  calculate their own SKID.  In
fact, look at this part of section 4.2.1.2 of RFC3280:

   For CA certificates, subject key identifiers SHOULD be 
   derived from the public key or a method that generates 
   unique values.

Here, 3280 is saying you should derive the SKID from the public key, it says
nothing about making use of any existing  key identifier that the CA is
putting as the AKID in certificates it issues.  But wait!  If you read down
a little further, you get: 

   Where a key identifier has not been previously 
   established, this specification RECOMMENDS use of one 
   of these methods for generating keyIdentifiers.  Where
   a key identifier has been previously established, the 
   CA SHOULD use the previously established identifier.

I see shoulds and recommends here, and not MUSTs.  Prior experience has
shown me that two CAs configured in different ways (or running different
software) may both derive the SKID from the public key in two different
fashions, and you can end up with the following:

+------------------+                +--------------------+
|  Allied Pilots   |                |     Boeing Root    |
| Association Root |                |                    |
|                  |                | SKID: Q            |
| SKID: A          |                |                    |
+------------------+                +--------------------+
         \                                   /
          \                                 /
           V                               V
    =================================================
    | +-------------------+   +-------------------+ |
    | | American Airlines |   | American Airlines | |
    | |                   |   |                   | |
    | | SN: 12345         |   | SN: 87654         | |
    | | SKID: Z           |   | SKID: F           | |
    | | AKID: A           |   | AKID: Q           | |
    | +-------------------+   +-------------------+ |
    =================================================
                            |
                            |
                            V
                  +-------------------+
                  |     Joe Pilot     |
                  |                   |
                  | SKID: W           |
                  | AKID: Z           |
                  +-------------------+

Although the public key has remained the same, American Airlines now has two
certificates with two different SKIDs but the same public key. Again, there
is no reason why a path from Joe Pilot to the Boeing Root should not be
valid.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDkVI7041412 for <[e-mail]>; Wed, 22 Oct 2003 06:46:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MDkVPs041411 for ietf-pkix-bks; Wed, 22 Oct 2003 06:46:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDkTI7041406 for <[e-mail]>; Wed, 22 Oct 2003 06:46:29 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA331775; Wed, 22 Oct 2003 09:46:29 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <[e-mail]>, <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 09:45:22 -0400
Organization: Gemini Security Solutions, Inc.
Message-ID: <003601c398a2$bd625d50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9MDkUI7041407
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Ströder wrote:
> Steve Hanna wrote:
> > A decent MUA would understand that there may be more
> > than one cert with the same SKI. AKI/SKI is just a
> > hint.
>  > [..]
> > Note also that AKI/SKI chaining SHOULD NOT be checked
> > during path validation. To be more explicit, it's
> > NOT true that the SKI of a CA certificate must match
> > the AKI of a certificate signed by that CA.
> 
> Reading this discussion I ask myself:
> Is there any good reason to set AKI/SKI at all?
> Is it worth for anything?
> Or is it just YAPEB [1]?

Michael,

When a path-building implementation is building a path, and it comes
upon one subject with multiple certificates and is trying to determine
which one to use, AKID and SKID are useful, because if they match
properly, there is a high degree of confidence that the certificate(s)
with matching AKID/SKIDs is/are the correct certificate(s) to choose.

However, just because they do not match does not mean that there is no
"there" there.  The degree of confidence that it will lead to a valid
path is lessened somewhat, but there is still a chance that the path in
that direction will be valid.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDe7I7041091 for <[e-mail]>; Wed, 22 Oct 2003 06:40:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MDe7dE041090 for ietf-pkix-bks; Wed, 22 Oct 2003 06:40:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDe5I7041084 for <[e-mail]>; Wed, 22 Oct 2003 06:40:06 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA280568; Wed, 22 Oct 2003 09:39:52 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 09:38:44 -0400
Organization: Gemini Security Solutions, Inc.
Message-ID: <003501c398a1$d0c0d1c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <005401c39818$b9d6e050$[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

> Based on a review of Sections 4.2.1.2 and 4.2.1.1 of 
> 3280, I draw the following conclusion: A 3280 compliant
> CA MUST ensure that AKI and SKI chain properly.  This 
> is sufficient for path construction.  Thus, I do not 
> see a particular need to change 3280 in this area.

I read this differently.  I agree that for a given CA, that CA must make
sure that for certificates it issues, the AKID and SKID must match.
However, when you add the "IssuerDN/Serial" tuple version of AKID, that
can no longer be true.  When you start interoperating across domains,
there are times at which AKID and SKID will not match, but yet it should
lead to a valid path.  Consider the following example:

+------------------+                +--------------------+
|  Allied Pilots   |                |     Boeing Root    |
| Association Root |                |                    |
|                  |                | SKID: Q            |
| SKID: A          |                |                    |
+------------------+                +--------------------+
         \                                   /
          \                                 /
           V                               V
    =================================================
    | +-------------------+   +-------------------+ |
    | | American Airlines |   | American Airlines | |
    | |                   |   |                   | |
    | | SN: 12345         |   | SN: 87654         | |
    | | SKID: Z           |   | SKID: Z           | |
    | | AKID: A           |   | AKID: Q           | |
    | +-------------------+   +-------------------+ |
    =================================================
                            |
                            |
                            V
                  +-------------------+
                  |     Joe Pilot     |
                  |                   |
                  | SKID: W           |
                  | AKID: "American   |
                  |        Airlines,  |
                  |        12345"     |
                  +-------------------+

In our example, we have the "American Airlines" entity which has two
certificates, one issued by the Allied Pilots Association (AA's union)
and the other by Boeing (one of their manufacturers).  These two
certificates have the same public key and subject public key identifier,
but different serial numbers.  "American Airlines" issues a certificate
to "Joe Pilot".  Although Joe Pilot's AKID points to the AA Root
certificate issued by the Allied Pilots Association, there is no reason
why a path to the Boeing Root should not be found equally acceptable.

The other thing at play was what Steve Hanna mentioned in an earlier
message.  Currently, there is no commonly accepted way to for a
cross-certifying CA to accept the desired SKID in a request for
cross-certification.  Therefore, many CAs  calculate their own SKID.  In
fact, look at this part of section 4.2.1.2 of RFC3280:

   For CA certificates, subject key identifiers SHOULD be 
   derived from the public key or a method that generates 
   unique values.

Here, 3280 is saying you should derive the SKID from the public key, it
says nothing about making use of any existing  key identifier that the
CA is putting as the AKID in certificates it issues.  But wait!  If you
read down a little further, you get: 

   Where a key identifier has not been previously 
   established, this specification RECOMMENDS use of one 
   of these methods for generating keyIdentifiers.  Where
   a key identifier has been previously established, the 
   CA SHOULD use the previously established identifier.

I see shoulds and recommends here, and not MUSTs.  Prior experience has
shown me that two CAs configured in different ways (or running different
software) may both derive the SKID from the public key in two different
fashions, and you can end up with the following:

+------------------+                +--------------------+
|  Allied Pilots   |                |     Boeing Root    |
| Association Root |                |                    |
|                  |                | SKID: Q            |
| SKID: A          |                |                    |
+------------------+                +--------------------+
         \                                   /
          \                                 /
           V                               V
    =================================================
    | +-------------------+   +-------------------+ |
    | | American Airlines |   | American Airlines | |
    | |                   |   |                   | |
    | | SN: 12345         |   | SN: 87654         | |
    | | SKID: Z           |   | SKID: F           | |
    | | AKID: A           |   | AKID: Q           | |
    | +-------------------+   +-------------------+ |
    =================================================
                            |
                            |
                            V
                  +-------------------+
                  |     Joe Pilot     |
                  |                   |
                  | SKID: W           |
                  | AKID: Z           |
                  +-------------------+

Although the public key has remained the same, American Airlines now has
two certificates with two different SKIDs but the same public key.
Again, there is no reason why a path from Joe Pilot to the Boeing Root
should not be valid.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDQdI7040567 for <[e-mail]>; Wed, 22 Oct 2003 06:26:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MDQdnq040566 for ietf-pkix-bks; Wed, 22 Oct 2003 06:26:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDQcI7040561 for <[e-mail]>; Wed, 22 Oct 2003 06:26:38 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h9MDQVTX028554; Wed, 22 Oct 2003 09:26:31 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002007bbbc3474b916@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 22 Oct 2003 09:21:25 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 20:26 +1300 10/22/03, Peter Gutmann wrote:
>"Al Arsenault" <[e-mail]> writes:
>
>>Okay, it's only a SHOULD, not a MUST, but the scenario you reference below
>>only comes in to play if I signed the CMS message using my CA cert, not my
>>end-entity cert.
>>
>>Got an example where this is relevant if the sKID's of two different CA certs
>>are the same? 
>
>My CMS example from earlier used with SCEP.
>
>In any case something like this should never be allowed to happen as a matter
>of basic protocol design.  Creating a "unique" key ID and then specifically
>telling people they can use non-unique IDs is just asking for trouble.
>
>Peter.

Peter,

SCEP is not an IETF standard, and it sounds as if it's use of these 
extensions is not consistent with the guidance provided in 2459, and 
now in 3280. Whose fault is that?

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDO9I7040291 for <[e-mail]>; Wed, 22 Oct 2003 06:24:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MDO1rB040278 for ietf-pkix-bks; Wed, 22 Oct 2003 06:24:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDNhI7040079 for <[e-mail]>; Wed, 22 Oct 2003 06:23:44 -0700 (PDT) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 14:20:22 +0100
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Oct 2003 14:19:35 +0100
Received: from mail-lul.microsoft.com ([65.53.188.37]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 14:15:11 +0100
Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 22 Oct 2003 15:13:12 +0200
Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Oct 2003 14:25:48 +0200
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 22 Oct 2003 12:10:07 +0200
x-mimeole: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 11:09:02 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AKI and SKI problem with RFC 3280?
Thread-Index: AcOYeaWbTIQQjbRFSaWQfl9Q+kOxmQACiVeg
From: "Stefan Santesson" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 22 Oct 2003 10:10:07.0735 (UTC) FILETIME=[AB86D070:01C39884]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9MDNiI7040146
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Peter,

I think this is asking for trouble. That is my whole point.

/Stefan

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Peter Gutmann
> Sent: den 22 oktober 2003 09:26
> To: [e-mail]; [e-mail]; [e-mail];
Stefan
> Santesson
> Cc: [e-mail]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> 
> "Al Arsenault" <[e-mail]> writes:
> 
> >Okay, it's only a SHOULD, not a MUST, but the scenario you reference
> below
> >only comes in to play if I signed the CMS message using my CA cert,
not
> my
> >end-entity cert.
> >
> >Got an example where this is relevant if the sKID's of two different
CA
> certs
> >are the same?
> 
> My CMS example from earlier used with SCEP.
> 
> In any case something like this should never be allowed to happen as a
> matter
> of basic protocol design.  Creating a "unique" key ID and then
> specifically
> telling people they can use non-unique IDs is just asking for trouble.
> 
> Peter.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MCv0I7039193 for <[e-mail]>; Wed, 22 Oct 2003 05:57:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MCv0HQ039192 for ietf-pkix-bks; Wed, 22 Oct 2003 05:57:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MCuwI7039184 for <[e-mail]>; Wed, 22 Oct 2003 05:56:58 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h9MCurTX027097; Wed, 22 Oct 2003 08:56:54 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002003bbbc2da11fc1@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 22 Oct 2003 08:53:38 -0400
To: Michael =?iso-8859-1?Q?Str=F6der?=  <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: AKI and SKI problem with RFC 3280?
Cc: [e-mail]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9MCuxI7039188
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:15 +0200 10/22/03, Michael Ströder wrote:
>Steve Hanna wrote:
>>A decent MUA would understand that there may be more
>>than one cert with the same SKI. AKI/SKI is just a
>>hint.
>  > [..]
>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>during path validation. To be more explicit, it's
>>NOT true that the SKI of a CA certificate must match
>>the AKI of a certificate signed by that CA.
>
>Reading this discussion I ask myself:
>Is there any good reason to set AKI/SKI at all?
>Is it worth for anything?
>Or is it just YAPEB [1]?
>
>Ciao, Michael.
>
>[1] yet another PKIX extension bloat

Michael,

If you read 3280 and 2459, you'll note that the 
primary use of these extensions is to allow one 
to perform more efficient path discovery, by 
helping select the right cert when more than one 
(CA) cert matches based on Subject/Issuer 
relationship.  Most of the complaints I hear are 
a result form trying to misuse the AKI/SKI as a 
search key. It's inappropriate to complain about 
how poorly your screwdriver works as a cold 
chisel.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MCVAI7038442 for <[e-mail]>; Wed, 22 Oct 2003 05:31:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MCVAUE038441 for ietf-pkix-bks; Wed, 22 Oct 2003 05:31:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MCV8I7038435 for <[e-mail]>; Wed, 22 Oct 2003 05:31:08 -0700 (PDT) (envelope-from [e-mail])
Received: from serbius (kasiski.secorvo.de [194.45.12.203]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id OAA22898; Wed, 22 Oct 2003 14:29:22 +0200
From: "Stefan Kelm" <[e-mail]>
Organization: Secorvo Security Consulting GmbH
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Date: Wed, 22 Oct 2003 14:30:16 +0200
MIME-Version: 1.0
Subject: Re: The value of qualified certificates
Reply-to: [e-mail]
Message-ID: <3F969478.27945.FF189B@localhost>
In-reply-to: <016d01c39887$03486970$0500a8c0@arport>
X-mailer: Pegasus Mail for Windows (v4.11)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

> I'm wondering what the value of qualified certificates is,
> when e-governments in country after country, buy certificates
> from commercial CAs where each CA (or CA network) requires
> a business contract with each RP.  As these contracts regulate
> liabilities etc. it seems that the legal implications of qualified
> certificates become limited or are eliminated.  What's left seems
> to only be a certificate profile. I.e. a "format".  Among many such.

Good point.

In this regard you might want to have a look at a report titled "The 
Legal and Market Aspects of Electronic Signatures" which has been 
published by the European Commission only yesterday: 

http://europa.eu.int/information_society/eeurope/2005/index_en.htm  

Cheers,

	Stefan.
--------------------------------------------------------
http://www.Anti-Spam-Symposium.de  18.-19. November 2003
--------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. [phone], Fax [phone]
E-Mail [e-mail], http://www.secorvo.de/
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MCBmI7037901 for <[e-mail]>; Wed, 22 Oct 2003 05:11:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MCBm0j037899 for ietf-pkix-bks; Wed, 22 Oct 2003 05:11:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MCBlI7037889 for <[e-mail]>; Wed, 22 Oct 2003 05:11:47 -0700 (PDT) (envelope-from [e-mail])
Received: from arsenaultd2 (col-dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id h9MCBSTW025234; Wed, 22 Oct 2003 08:11:29 -0400 (EDT)
From: "Al Arsenault" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 08:08:29 -0400
Message-ID: <[e-mail]>
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: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Okay, now I'm *truly* confused.


-----Original Message-----
From: Peter Gutmann [mailto:[e-mail]]
Sent: Wednesday, October 22, 2003 3:26 AM
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Cc: [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?


"Al Arsenault" <[e-mail]> writes:

>Okay, it's only a SHOULD, not a MUST, but the scenario you reference below
>only comes in to play if I signed the CMS message using my CA cert, not my
>end-entity cert.
>
>Got an example where this is relevant if the sKID's of two different CA
certs
>are the same?

My CMS example from earlier used with SCEP.

awa:> Um, the current spec for SCEP appears to be
http://www.ietf.org/internet-drafts/draft-nourse-scep-08.txt

awa:> From that, it appears that:

awa:>    (a) SCEP doesn't use CMS, it uses PKCS #7
awa:>    (b) SCEP doesn't support the use of sKID or aKID as an identifier
in the signerInfo, it's restricted to
	     issuerAndSerialNumber (which, oh-by-the-way, is not guaranteed to be
unique in the real world, since I can set up
		a CA of my own reusing an issuer name that's already out there :-)
awa:>    (c) this is only relevant when the certificate requester is
creating a self-signed "CA" cert for the purpose of establishing the
connection with the CA, anyway.

awa:> So, your assertion is that a bastardized hybrid of a widely-used but
non-standard protocol (SCEP) with an updated wrapping mechanism (CMS) will
cause problems for some types of signature validation software, and this is
a reason why one option permitted by PKIX is a fundamental flaw?


In any case something like this should never be allowed to happen as a
matter
of basic protocol design.  Creating a "unique" key ID and then specifically
telling people they can use non-unique IDs is just asking for trouble.


awa:> I don't have any great love for the "monotonically increasing integer
sequence" mechanism myself, particularly since we've had a number of
discussions about what "monotonically increasing" means (different sources
have different definitions; some definitions allow the repitition of numbers
as pointed out by Peter Sylvester).  All PKIs in which I've ever been
involved have either used the "low-order 60 bits of a SHA-1 hash" or the
"full SHA-1 hash". The bottom line, though, is that I think anybody who
builds cert validation software for a large, complex system with multiple
CA's, multiple extensions, etc., and who believes that "if the sKID matches,
I am guaranteed to have found the right certificate" is being somewhat
simple in his software design.

		Al Arsenault



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MATaI7034421 for <[e-mail]>; Wed, 22 Oct 2003 03:29:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MATaDJ034420 for ietf-pkix-bks; Wed, 22 Oct 2003 03:29:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.fre.skanova.net (smtp2.fre.skanova.net [195.67.227.95]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MATYI7034414 for <[e-mail]>; Wed, 22 Oct 2003 03:29:35 -0700 (PDT) (envelope-from [e-mail])
Received: from arport (t10o913p16.telia.com [213.64.27.136]) by smtp2.fre.skanova.net (8.12.10/8.12.10) with SMTP id h9MATW3M022366 for <[e-mail]>; Wed, 22 Oct 2003 12:29:33 +0200 (CEST)
Message-ID: <016d01c39887$03486970$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: The value of qualified certificates
Date: Wed, 22 Oct 2003 12:26:50 +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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm wondering what the value of qualified certificates is,
when e-governments in country after country, buy certificates
from commercial CAs where each CA (or CA network) requires
a business contract with each RP.  As these contracts regulate
liabilities etc. it seems that the legal implications of qualified
certificates become limited or are eliminated.  What's left seems
to only be a certificate profile. I.e. a "format".  Among many such.

Just my 2 (EU) cents

Anders R


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M8GsI7002176 for <[e-mail]>; Wed, 22 Oct 2003 01:16:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9M8GsLP002175 for ietf-pkix-bks; Wed, 22 Oct 2003 01:16:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (du-006-105.access.de.clara.net [212.82.229.105]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M8GqI7002157 for <[e-mail]>; Wed, 22 Oct 2003 01:16:53 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id B25CD22C5F for <[e-mail]>; Wed, 22 Oct 2003 10:15:53 +0200 (CEST)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 6240B18FA1 for <[e-mail]>; Wed, 22 Oct 2003 10:15:52 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 22 Oct 2003 10:15:52 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna wrote:
> A decent MUA would understand that there may be more
> than one cert with the same SKI. AKI/SKI is just a
> hint.
 > [..]
> Note also that AKI/SKI chaining SHOULD NOT be checked
> during path validation. To be more explicit, it's
> NOT true that the SKI of a CA certificate must match
> the AKI of a certificate signed by that CA.

Reading this discussion I ask myself:
Is there any good reason to set AKI/SKI at all?
Is it worth for anything?
Or is it just YAPEB [1]?

Ciao, Michael.

[1] yet another PKIX extension bloat



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M7PSI7089398 for <[e-mail]>; Wed, 22 Oct 2003 00:25:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9M7PSOJ089397 for ietf-pkix-bks; Wed, 22 Oct 2003 00:25:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M7PQI7089384 for <[e-mail]>; Wed, 22 Oct 2003 00:25:27 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9M7PIRS017287; Wed, 22 Oct 2003 20:25:18 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9M7QH013754; Wed, 22 Oct 2003 20:26:17 +1300
Date: Wed, 22 Oct 2003 20:26:17 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Al Arsenault" <[e-mail]> writes:

>Okay, it's only a SHOULD, not a MUST, but the scenario you reference below
>only comes in to play if I signed the CMS message using my CA cert, not my
>end-entity cert.
>
>Got an example where this is relevant if the sKID's of two different CA certs
>are the same?  

My CMS example from earlier used with SCEP.

In any case something like this should never be allowed to happen as a matter
of basic protocol design.  Creating a "unique" key ID and then specifically
telling people they can use non-unique IDs is just asking for trouble.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M7MgI7088766 for <[e-mail]>; Wed, 22 Oct 2003 00:22:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9M7Mg60088765 for ietf-pkix-bks; Wed, 22 Oct 2003 00:22:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M7MdI7088735 for <[e-mail]>; Wed, 22 Oct 2003 00:22:40 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9M7MXRS017174; Wed, 22 Oct 2003 20:22:33 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9M7NV513736; Wed, 22 Oct 2003 20:23:31 +1300
Date: Wed, 22 Oct 2003 20:23:31 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Peter Hesse" <[e-mail]> writes:

>Path building implementations should never rely on them being correct.

What's the point of having them at all then?  If you can't rely on them then
you need to have something you can rely on, and if you've got that anyway then
the unreliable alternative is superfluous.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LLd3I7041898 for <[e-mail]>; Tue, 21 Oct 2003 14:39:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LLd3Pg041897 for ietf-pkix-bks; Tue, 21 Oct 2003 14:39:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LLd2I7041892 for <[e-mail]>; Tue, 21 Oct 2003 14:39:02 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9LLcwxA022951; Tue, 21 Oct 2003 14:38:59 -0700 (PDT)
Received: from Sun.COM (sr1-ubur-03 [129.148.9.82]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h9LLcwB18110; Tue, 21 Oct 2003 17:38:58 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2003 17:38:58 -0400
From: Yassir Elley <[e-mail]>
Reply-To: [e-mail]
Organization: Sun Microsystems Inc. - BDC
X-Mailer: Mozilla 4.79C-CCK-MCD  [en] (X11; U; SunOS 5.9 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: [Fwd: 3rd Annual PKI R&D Workshop - Call for Papers]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI

-------- Original Message --------
Subject: 3rd Annual PKI R&D Workshop - Call for Papers
From: Neal McBurnett <[e-mail]>

        3rd Annual PKI R&D Workshop - Call for Papers
           http://middleware.internet2.edu/pki04/

Jointly sponsored by NIH, NIST, and Internet2, in cooperation with
USENIX and OASIS.

This workshop considers the full range of public key technology used
for security decisions. PKI supports a variety of functionalities
including authentication, authorization, identity (syndication,
federation and aggregation) and trust.

We solicit papers, scenarios, war stories, panel proposals, and
participation from researchers, systems architects, vendor engineers
and above all users.

Location:                 NIST, Gaithersburg MD, USA.
Papers and Proposals due: January 30, 2004
Authors Notified:         March 1, 2004
Final Materials Due:      March 22, 2004
Workshop Dates:           April 12-14, 2004

This workshop has three goals:

  * Explore the current state of public key technology in different
    domains including web services, grid technologies, authentication
    systems et. al. in academia & research, government and industry.
  * Share & discuss lessons learned and scenarios from vendors and
    practitioners on current deployments
  * Provide a forum for leading security researchers to explore the
    issues relevant to the PKI space in areas of security management,
    identity, trust, policy, authentication and authorization.

The results will be promulgated in several ways, including:
  * a published proceedings with refereed papers and summaries of
    workshop discussions
  * the workshop web site: http://middleware.internet2.edu/pki04/
  * experimental initiatives within higher education

Outstanding papers will be invited for possible publication in ACM
TISSEC.

Presentation formats will include:
  * Refereed papers
  * Panel discussions
  * Invited talks
  * Work-in-progress updates

Submitted works for panels, papers and reports should address one or
more critical areas of inquiry. Topics include (but not are not
limited to):
  * PKI systems in various domains like grid, web services,
    government, industry and academia.
  * PKI and Federated trust
  * Related standards: x509, SDSI/SPKI, PGP, XKMS, SAML, Shibboleth,
    Liberty Alliance, etc.
  * Cryptographic methods in support of security decisions
  * The characterization and encoding of security decision data
  * Security protocols and choreographies - new ideas, analysis of
    existing systems et al
  * Alternative methods for supporting security decisions
  * Intersection of Policy based systems and PKI
  * Privacy protection and implications of different approaches
  * Scalability of security systems - are there limits to growth?
  * Security of the various components of a system: private keys, root
    authorities, certificate storage, communications channels, code,
    directories, etc.
  * Mobility solutions
  * Approaches to attributes and delegation
  * Improved designs for security-related user interfaces
  * Human factors issues with naming, multiple private keys, selective
    disclosure
  * Discussion of how the "public key infrastructure" may differ from
    the "PKI" traditionally defined
  * Reports of real-world experience with the use and deployment of
    PKI, especially where future research directions for PKI are
    indicated
  * What is missing? The gaps in PKI research and standards from a
    systems engineering point-of-view


Submissions and Additional Information

Papers should be submitted electronically, in PDF, formatted for
standard US letter-size paper (8.5 x 11 inches). The final version of
refereed papers should ideally be between 8 and 15 pages, and in no
case more than 20 pages. They should have no header or footer text
(e.g., no page numbers).

Proposals for panels should be no longer than five pages in length and
should include possible panelists and an indication of which of those
panelists have confirmed participation.

Please submit the following information by email to
[e-mail]:
  * The full contact details (name, affiliation, email, phone, postal
    address) of one author who will act as the primary contact for
    this paper.
  * The full list of authors: you must supply the first name, the last
    name and the affiliation of each author.
  * The finished paper in PDF format as an attachment.

All submissions will be acknowledged.

The deadline for submission is January 30, 2004. Requests for short
extensions will be granted on a case-by-case basis, and must be
requested by January 30th via email to the same address.

When appropriate, authors should arrange for a release for publication
from their employer prior to submission. Papers accompanied by
non-disclosure agreement forms are not acceptable and will be returned
to the author(s) unread.

Submissions of papers must not substantially duplicate work that any
of the authors have published elsewhere or have submitted in parallel
to any other conferences or journals.

The registration fee will be waived for presenters. A limited number
of stipends are available to those unable to obtain funding to attend
the workshop. Further information will be available on the
registration page in January.


Program Committee

   Peter Alterman       NIH
   Matt Blaze           AT&T Labs Research
   Bill Burr            NIST
   Yassir Elley         Sun Microsystems
   Carl Ellison         Microsoft
   Stephen Farrell      Trinity College Dublin, 
   Richard Guida        Johnson & Johnson
   Peter Honeyman       University of Michigan
   Russ Housley         Vigil Security LLC
   Ken Klingenstein     University of Colorado
   Olga Kornievskaia    University of Michigan
   Neal McBurnett       Internet2
   Clifford Neuman      USC
   Eric Norman          University of Wisconsin
   Tim Polk             NIST
   Ravi Sandhu          George Mason University; NSD Security
   Krishna Sankar       Cisco Systems
   Jeff Schiller        MIT
   Frank Siebenlist     Argonne National Laboratory
   Sean Smith           Dartmouth College
   Michael Wiener       Cryptographic Clarity

General Chair: 
   Ken Klingenstein, University of Colorado.

Program Chair:
   Krishna Sankar, Cisco Systems.

Steering Committee Chair:
   Neal McBurnett, Internet2.

Local Arrangements Chair:
   Nelson Hastings, NIST.

---------------------------------------------------mw-pkiprgmcommittee-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

---------------------------------------------------mw-pkiprgmcommittee--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LLHPI7041292 for <[e-mail]>; Tue, 21 Oct 2003 14:17:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LLHPIm041291 for ietf-pkix-bks; Tue, 21 Oct 2003 14:17:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LLHOI7041285 for <[e-mail]>; Tue, 21 Oct 2003 14:17:24 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id h9LLHPDb002021 for <[e-mail]>; Tue, 21 Oct 2003 17:17:25 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Tue, 21 Oct 2003 17:17:17 -0400
Message-ID: <005401c39818$b9d6e050$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9LLHOI7041287
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Based on a review of Sections 4.2.1.2 and 4.2.1.1 of 3280, I draw the
following conclusion: A 3280 compliant CA MUST ensure that AKI and SKI chain
properly.  This is sufficient for path construction.  Thus, I do not see a
particular need to change 3280 in this area.

The various methods for calculating these values and their probability of
collision need not be described in 3280.  As others have pointed out, AKI
and SKI need not be unique or different globally.  For efficient path
development, it is sufficient that AKI and SKI be different, with high
degree of probability, for different keys of the same entity.  The algorithm
chosen can be left up to the CA.  The proper chaining of AKI and SKI (not
for path validation, but for path construction) is important.  By proper
chaining, I mean that the SKI in certificate(s) issued to a CA for a
specific public key should (I read 3280 to say MUST, and I like that over
SHOULD) match the AKI in those certificates that the CA issues which are
verified using the said specific public key.

Santosh Chokhani
Orion Security Solutions, Inc.
1489 Chain Bridge Road, Suite 300
McLean, Virginia 22101
[phone]  Ext. 35(voice)
[phone] (Fax)
[e-mail]
Visit our Web site
http://www.orionsec.com







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LJ3JI7036013 for <[e-mail]>; Tue, 21 Oct 2003 12:03:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LJ3J9q036012 for ietf-pkix-bks; Tue, 21 Oct 2003 12:03:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LJ3II7036007 for <[e-mail]>; Tue, 21 Oct 2003 12:03:18 -0700 (PDT) (envelope-from [e-mail])
Received: from wmcooper (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id h9LJ3JDb014937; Tue, 21 Oct 2003 15:03:19 -0400
From: "Matt Cooper" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt
Date: Tue, 21 Oct 2003 15:03:13 -0400
Message-ID: <002001c39805$fdb6cd20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9LJ3II7036008
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Alice,

Thanks for the thorough reading! You made a lot of good suggestions that
will help clarify the I-D. Please see my comments below.

Best Regards,
Matt

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alice Sturgeon
 
> Terminology, on "certification path building" and its aka's:  
> How can "building" be the same as "discovery", which would be 
> more like the validation process?  Also, using the verb 
> "obtain" does not make it clear whether it is the building 
> (construction, development) or the discovery (finding, 
> validating) that is being described, although, given the 
> subject of the I-D, we only assume it is the former 
> (building).

We had a few rounds of discussion on the term to use here and settled on
building. You are correct, the focus is on constructing a likely to validate
path, not validating it. I think the connotations of each aka also vary
according to whom you ask. =) I also agree that "obtain" should be replaced
with a better verb. How about "assemble"? I think that is more in line with
what we meant.

> Terminology, on "subscriber" - You might consider stating 
> something like: "also referred to as 'user' or, in a 
> certification hierarchy, 'End Entity'". Many use "subscriber" 
> and "user" synonymously and so it might be helpful to clarify 
> that (or your thinking on the two terms), and you use End 
> Entity, and so your view on its relationship to "subscriber" 
> as certificate subject would be helpful.  Stating these 
> equivalents here would also avoid having to do so in the 
> later text (e.g., in 1.4, "end entities' (subscribers')" in 
> 1st para.).

This is tricky to dance around and I obviously didn't do too great a job!
The "End Entity" of the path is not necessarily a subscriber/user. For
example, you may be building a path for a CRL signer. Hence, I tried to
steer clear of the subscriber/user terms unless an example was specifically
citing that type of cert. I think it ended up a little messy. I will review
for this usage and see what I can do to make it more consistent.

> Terminology: In view of your last two terms, you might 
> consider trying to define "trust" - rather critical to the 
> whole I-D concept.  While you use the term extensively in the 
> Introduction, it does seem to be assumed that the concept is 
> understood - and it is in a general sense, but it might be 
> prudent to define explicitly for this context.  For example, 
> are there well defined security attributes that make up 
> "trust" - confidentiality, integrity, accountability, 
> authenticity, or (gulp) non-repudiation?

I agree, but I'm a little concerned about trying to boil down what is a
fairly broad concept as it is applied to PKI in a definition. Perhaps a to
the point definition with 3280 as suggested reading?  It may make sense for
us to explicitly point out in the introduction that that the I-D assumes the
reader understands the contents of 3280 and related documents. I'll give
this some more thought.

> With respect to 1.4.3 and the text on figure 4, and the two 
> principal concerns about vulnerability:  If the cert path 
> building software is written correctly, then transitive trust 
> should be impossible.  

It's not so much a vulnerability as a result of many cooks in the kitchen.
If I cross certify with you today, and tomorrow you cross certify with ACME
PKI, I may now trust ACME PKI without intending to. Of course, there are
ways to design the certificates to prevent this. Problem is in my mind, as
the number of variables (cross certified infrastructures) grows, it becomes
increasingly difficult to keep track of the possibilities. IMO, limiting the
number of combinations is one of the very nice properties of having a single
bridge rather than "meshing" the infrastructures.

> Secondly, I would think that cert 
> policy mapping should prohibit the cross-certification of 
> PKIs with different assurance levels.

Agree, it _should_. =) Again, the worry is similar what I described just
above. If I give you a cert with high assurance, and you certify a lower
assurance PKI and map the policy to it, then I have a problem without
realizing it. Or perhaps, you correctly give ACME PKI the high assurance
cert, and they in turn cross certify with a lower assurance PKI and keep the
policy intact. Again, you can control all these things to varying degrees
with name constraints, path length cons, etc., but I think we have to take
the human factor of PKI design into consideration and be somewhat realistic
with our expectations.

> 1.4.4 says:
> However, when connecting PKIs in this way, the number and 
> variety of PKIs involved results in a non-hierarchical 
> environment, such as the one as depicted in Figure 5. I don't 
> think this is quite true, or perhaps just a simplification: 
> The overall environment or framework (or super-structure) is 
> non-hierarchical, but within that framework there is indeed a 
> hierarchical environment.  This is an important point, 
> because it shows how the bridge, as non-hierarchical 
> framework, can simplify the one or many hierarchical 
> structure(s) within it for the purpose of cross-certification.

I'm not sure I'm understanding what you are saying. Are you saying we should
at this point stress that although the overall graph is non-hierarchical,
that the trust framework is still hierarchical?

> 1.5 - First reason given for supporting the bridge structure 
> is gratuitous - Use it because it is used...  I think this 
> point (1) detracts from point (2), which is a much more 
> important reason.

I agree and see no problem removing that and focusing on (2).

> RFC 3280 6.2 states:  While each certification path begins 
> with a specific trust anchor, ... So why is path building 
> beginning with the trusted root called "reverse"?  I assume 
> this is because for cert path validation, one logically 
> starts with the EE cert. So - different purposes, different 
> terminology?

I think this is throw back to prior terminology for cross certificates. The
reverse cross certificates are those issued from a CA, the forward are those
issued to the CA. If building from the EE, you use the forward, when
building from the TR, you use the reverse, hence the naming of the
respective building directions. I think, though I may start a religious
debate here, "forward" was chosen as a natural result of that being the
intended/designed direction for path building. (It certainly isn't forward
with respect to issuance!)

> 2.4.1, last sentence of 1st indented paragraph says:
> "In other words, consumption of such paths by relying parties 
> could potentially yield trust in unintended ways." Assuming 
> (perhaps incorrectly) that "trust in unintended ways" means 
> "unintended trust", then the path actually creates a 
> vulnerability, does it not?

Yes, and I agree with you, but I did intentionally soft pedal that.
Basically, if everyone did everything just right, there should, in theory,
not be any unintended trust. The problem is to my mind that allowing these
unnecessarily convoluted paths increases the number of variables
exponentially; making it next to impossible for a PKI designer to consider
every possible outcome, and therefore, every possible trust path. More to
the point, I don't think the convoluted path in and of itself is a
vulnerability, but I think it creates the potential for masking a
vulnerability/unintended trust.

> Second point also could be 
> identified as a vulnerability, in that the path 
> unintentionally lowers the assurance level.

Agree to an extent as well; but this has been a topic of much debate in the
past with no clear winner. Hence the "may be considered lost" verbiage as
opposed to "is lost." I'm in the latter school of thought and I personally
would like to see this become part of path validation rather than a
recommended approach to path building. Perhaps it is time for the list to
re-visit this topic...

> 2.4 states:
> "The BCA also has issued four certificates, one to each of 
> the trust roots." But then 2.4.2 states: "It is not possible 
> to build forward direction paths into the infrastructures 
> behind CAs W, Y, and Z, because W, Y, and Z have not been 
> issued certificates by any other CAs." I'm missing something 
> on this point.

I agree this isn't clear enough and I think we should try to clarify this
point because it is an important one to my mind. The idea is, for example,
suppose I'm building a (forward) path from E to TR-X. It isn't possible for
my forward path builder to go astray and wander into the infrastructure
behind TR-W because TR-W was not issued certificates by either F or G. (The
builder would be forced to "go back" at W)  However, the same example
flipped around building (in reverse) from TR-X to E, the path builder could
wander into the infrastructure behind TR-W using the certificates issued
from TR-W to F and/or G. The reverse builder than may not recurse back until
all paths behind TR-W are exhausted.

> >From the References: [RFC 1738]  Berners-Lee, T., L. Masinter and M.
> McCahill, "Uniform Resource Locators (URL)", RFC 1738, 
> December 1994. You may wish to reference, instead or in 
> addition, RFC 2396 URI Berners-Lee, T., Fielding, R., Irving, 
> U.C., and L. Masinter. "Uniform Resource Identifiers (URI): 
> Generic Syntax", August 1998.  RFC 2396 updates and merges 
> RFC 1738 (as well as "Relative Uniform Resource Locators" 
> [RFC1808]), although 2396 excludes the portions of RFC 1738 
> that define the specific syntax of individual URL schemes.  
> (And you use "URI" much more frequently than "URL".) Are the 
> references intended to be Normative or Informative?  I 
> believe it is necessary now to distinguish references now on 
> this basis.

You are correct; we need to update this section.

> 8. Security Considerations - In the 2nd and 3rd sentences, 
> you state the need to protect the trusted root cert, as well 
> as the trusted root keys.  It is necessary that the root cert 
> be available for the path. It is root keys that need to be 
> "kept safe" and of course only the public key should be 
> obtainable.  Suggest deleting trusted root cert from this discussion.

I agree the key is all that matters, but wrote it this way so as to not
diminish the importance of protecting the cert if that is the source of the
key. Perhaps a re-wording would be better:

The only exception to this is the appropriate protection of the trusted root
key(s) (or trusted root certificates if they are the source of the trusted
keys) used for validating paths.

?

> Editorial notes:

Thank you for these as well; we will address these items in the next
revision.

Thanks again for your efforts!





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LH0WI7031850 for <[e-mail]>; Tue, 21 Oct 2003 10:00:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LH0WKv031849 for ietf-pkix-bks; Tue, 21 Oct 2003 10:00:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LH0UI7031843 for <[e-mail]>; Tue, 21 Oct 2003 10:00:31 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA09786 for <[e-mail]>; Tue, 21 Oct 2003 19:00:26 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 21 Oct 2003 19:00:27 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id h9LH0Q403490 for [e-mail]; Tue, 21 Oct 2003 19:00:26 +0200 (MEST)
Date: Tue, 21 Oct 2003 19:00:26 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: PKIX agenda
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to know when an agenda for the
Minneapolis meeting will be available. 

I am not part of those who are able to go
without justification.  


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LGRqI7030805 for <[e-mail]>; Tue, 21 Oct 2003 09:27:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LGRq4C030804 for ietf-pkix-bks; Tue, 21 Oct 2003 09:27:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LGRmI7030797 for <[e-mail]>; Tue, 21 Oct 2003 09:27:51 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA09643 for <[e-mail]>; Tue, 21 Oct 2003 18:27:49 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 21 Oct 2003 18:27:49 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id h9LGRmI03445 for [e-mail]; Tue, 21 Oct 2003 18:27:48 +0200 (MEST)
Date: Tue, 21 Oct 2003 18:27:48 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A little bit of nit-picking the text in 3820:


>4.2.1.2
>     One common method for generating unique values is a monotonically
>     increasing sequence of integers.
  1, 1, 2, 2, 3, 3 is a monotonically increasing sequence of integers
according to some common definitions for sequences or functions.

As far as I remember my math classes from 30 years ago,
non-ambiguous terms are 'strictly increasing" or
"monotone and strictly increasing" or "monotonically
strictly increasing" ...


Peter


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LFqqI7029517 for <[e-mail]>; Tue, 21 Oct 2003 08:52:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LFqpbR029516 for ietf-pkix-bks; Tue, 21 Oct 2003 08:52:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.203]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LFqoI7029508 for <[e-mail]>; Tue, 21 Oct 2003 08:52:50 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft4.fr.colt.net with ESMTP id h9LFqfH18904 for <[e-mail]>; Tue, 21 Oct 2003 17:52:46 +0200
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2003 17:52:44 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031004
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna wrote:

>Note also that AKI/SKI chaining SHOULD NOT be checked
>during path validation. To be more explicit, it's
>NOT true that the SKI of a CA certificate must match
>the AKI of a certificate signed by that CA. Why?
>Because the CA certificate may have been issued by
>a CA that uses a different AKI/SKI computation technique
>than the CA who's the subject of the CA certificate.
>  
>
I really think it would be a better practice to always have a method of 
reusing existing SKI when emitting a cross-certificate.

It might be difficult with some currently used mecanisms for that, but 
cross-certificates for CA are not likemy to be an automatic process like 
the emission of a end-user certificate.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LFlWI7029358 for <[e-mail]>; Tue, 21 Oct 2003 08:47:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LFlWTq029357 for ietf-pkix-bks; Tue, 21 Oct 2003 08:47:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LFlWI7029352 for <[e-mail]>; Tue, 21 Oct 2003 08:47:32 -0700 (PDT) (envelope-from [e-mail])
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.10/) with ESMTP id h9LFlDxi003520; Tue, 21 Oct 2003 08:47:28 -0700 (PDT)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <VGG31HA4>; Tue, 21 Oct 2003 08:43:12 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, [e-mail]
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Tue, 21 Oct 2003 08:43:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

NO

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, October 15, 2003 2:03 PM
> To: [e-mail]
> Subject: POLL: Nonce-specific error code for OCSP
> 
> 
> 
> All,
> 
> I recently received permission from the chairs to poll the WG
> against the following question.
> 
> Should we standardize an OCSP *V1* error code that enables a
> responder to indicate its inability to respond to nonced
> requests?
> 
> Please respond with either YES or NO.
> 
> Mike
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LFeNI7029162 for <[e-mail]>; Tue, 21 Oct 2003 08:40:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LFeNeU029161 for ietf-pkix-bks; Tue, 21 Oct 2003 08:40:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LFeMI7029155 for <[e-mail]>; Tue, 21 Oct 2003 08:40:22 -0700 (PDT) (envelope-from [e-mail])
Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx2.magma.ca Magma's Mail Server with ESMTP id h9LFeMCv028556; Tue, 21 Oct 2003 11:40:22 -0400
Received: from hippolyta ([213.219.159.226]) by mail2.magma.ca (Magma's Mail Server) with SMTP id h9LFe395007989; Tue, 21 Oct 2003 11:40:20 -0400
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Peter Hesse" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt
Date: Tue, 21 Oct 2003 11:41:47 -0400
Message-ID: <[e-mail]>
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)
In-Reply-To: <00b501c389b0$c7babfa0$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,
This is an important effort and it is going to be very helpful once
finalized.
A few comments (with the humble caveat that those of you who wrote this I-D,
and with whom you consulted, are considerably more knowledgeable on this
subject than I am!):

Terminology, on "certification path building" and its aka's:  How can
"building" be the same as "discovery", which would be more like the
validation process?  Also, using the verb "obtain" does not make it clear
whether it is the building (construction, development) or the discovery
(finding, validating) that is being described, although, given the subject
of the I-D, we only assume it is the former (building).  As the authors
state in Purpose, other documents, notably RFC 3280, go into cert path
validation, and so this I-D does not go there.

Terminology, on "subscriber" - You might consider stating something like:
"also referred to as 'user' or, in a certification hierarchy, 'End Entity'".
Many use "subscriber" and "user" synonymously and so it might be helpful to
clarify that (or your thinking on the two terms), and you use End Entity,
and so your view on its relationship to "subscriber" as certificate subject
would be helpful.  Stating these equivalents here would also avoid having to
do so in the later text (e.g., in 1.4, "end entities' (subscribers')" in 1st
para.).

Terminology: In view of your last two terms, you might consider trying to
define "trust" - rather critical to the whole I-D concept.  While you use
the term extensively in the Introduction, it does seem to be assumed that
the concept is understood - and it is in a general sense, but it might be
prudent to define explicitly for this context.  For example, are there well
defined security attributes that make up "trust" - confidentiality,
integrity, accountability, authenticity, or (gulp) non-repudiation?

With respect to 1.4.3 and the text on figure 4, and the two principal
concerns about vulnerability:  If the cert path building software is written
correctly, then transitive trust should be impossible.  Secondly, I would
think that cert policy mapping should prohibit the cross-certification of
PKIs with different assurance levels.

1.4.4 says:
However, when connecting PKIs in this way, the number and variety of PKIs
involved results in a non-hierarchical environment, such as the one as
depicted in Figure 5.
I don't think this is quite true, or perhaps just a simplification: The
overall environment or framework (or super-structure) is non-hierarchical,
but within that framework there is indeed a hierarchical environment.  This
is an important point, because it shows how the bridge, as non-hierarchical
framework, can simplify the one or many hierarchical structure(s) within it
for the purpose of cross-certification.

1.5 - First reason given for supporting the bridge structure is gratuitous -
Use it because it is used...  I think this point (1) detracts from point
(2), which is a much more important reason.

RFC 3280 6.2 states:  While each certification path begins with a specific
trust anchor, ...
So why is path building beginning with the trusted root called "reverse"?  I
assume this is because for cert path validation, one logically starts with
the EE cert.
So - different purposes, different terminology?

2.4.1, last sentence of 1st indented paragraph says:
"In other words, consumption of such paths by relying parties could
potentially yield trust in unintended ways."
Assuming (perhaps incorrectly) that "trust in unintended ways" means
"unintended trust", then the path actually creates a vulnerability, does it
not?
Second point also could be identified as a vulnerability, in that the path
unintentionally lowers the assurance level.

2.4 states:
"The BCA also has issued four certificates, one to each of the trust roots."
But then 2.4.2 states:
"It is not possible to build forward direction paths into the
infrastructures behind CAs W, Y, and Z, because W, Y, and Z have not been
issued certificates by any other CAs."
I'm missing something on this point.

>From the References: [RFC 1738]  Berners-Lee, T., L. Masinter and M.
McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
You may wish to reference, instead or in addition, RFC 2396 URI
Berners-Lee, T., Fielding, R., Irving, U.C., and L. Masinter. "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998.  RFC 2396 updates
and merges RFC 1738 (as well as "Relative Uniform Resource Locators"
[RFC1808]), although 2396 excludes the portions of RFC 1738 that define the
specific syntax of individual URL schemes.  (And you use "URI" much more
frequently than "URL".)
Are the references intended to be Normative or Informative?  I believe it is
necessary now to distinguish references now on this basis.

8. Security Considerations - In the 2nd and 3rd sentences, you state the
need to protect the trusted root cert, as well as the trusted root keys.  It
is necessary that the root cert be available for the path. It is root keys
that need to be "kept safe" and of course only the public key should be
obtainable.  Suggest deleting trusted root cert from this discussion.

Editorial notes:

Section 1, 1st para., last sentence: There should be an "s" on
"certificate".
1.4, 1st sentence, the phrase "often times" does not translate well nor may
not be as clear as, simply, "often".

1.4.4, 4th sentence (beginning with "Since each PKI...") is not a sentence:
There is one subordinate clause (beginning with "Since"), with two parts to
it (joined by "and") but no principal clause.  The sense of it is that the
next sentence should be the principal clause, but since that would make a
horribly long sentence, I would suggest simply removing the "Since" and
making that a stand-alone (and proper) sentence.

2, last sentence reads (not well):
Rather, guidance is provided on the technical issues that surround the path
building process, and the capabilities path building implementations require
in order to build certification paths successfully, irrespective of PKI
structures.
To make this easier to read (I had trouble), insert "on" before "...the
capabilities path...", and add the letter "d" to "require"
("...implementations required in order to build...")

The A's, B's, and C's in figure 6 are a little confusing.  It can be
understood but it might be easier to do so if you used a combination of
numbers and letters.


All for now.


Alice Sturgeon
Chair, Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC 1/SC 27
and
System Policy Architect & Manager Standards
SPYRUS

Office:  613-232-2350
Mobile: [phone]




-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Peter Hesse
Sent: Friday, October 03, 2003 9:18 AM
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt


All,

To save everyone the trouble of trying to read through our entire
internet draft a second time, the following lists outline the main
changes made in the document since version 00.

Overall changes:
- made certain terminology more consistent ("certification
   path" throughout the document instead of "certificate path",
   "cert path", etc.)
- softened the tone; made it clear that the document provides
   informational recommendations and does not prescribe a
   particular method for certification path building
- removed statements on the document providing guidance based
   on "best practices" but instead explicitly defined the
   motivation and purpose behind the document, as well as the
   criteria that led to the guidance provided.
- removed some non-ascii characters that had snuck in

Specific changes:
- Thoroughly updated section 1.1 (Motivation) and 1.2 (Purpose)
- updated terminology section to include a few additional terms
- updated mesh PKI figure to better differentiate it from other
   structures
- included a section (2.2) that clearly identifies the authors'
   criteria for a path building implementation
- broke up section 2.4 (How to Build a Certification Path) with
   some subsections
- added section 3.3 (Representing the Decision Tree
   Programmatically)
- updated section 3.5 to include additional information about
   the sorting methods that follow.  Sorting methods are no
   longer called "rules".
- added section 5.4 (Distinguished Name Encoding)
- added section 6.3 (Subject Information Access)

Cheers,

--Peter Hesse

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been
a statue set up in honor of a critic." --Jean Sibelius






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LElQI7027298 for <[e-mail]>; Tue, 21 Oct 2003 07:47:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LElQMW027297 for ietf-pkix-bks; Tue, 21 Oct 2003 07:47:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LElPI7027291 for <[e-mail]>; Tue, 21 Oct 2003 07:47:25 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9LElM5u022143; Tue, 21 Oct 2003 08:47:22 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h9LElMB18199; Tue, 21 Oct 2003 10:47:22 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2003 10:46:51 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Peter Hesse <[e-mail]>, Peter Gutmann <[e-mail]>, [e-mail], [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson wrote:
> What is in fact the current behaviour of applications today:
> 
> Do they:
> 1) Not even try to validate the path since issuer/subject don't match
> 2) Fail validation and display error
> 3) Fail validation, then goes back and search for another path

In Sun's JDK 1.4.x, we ignore AKI/SKI so an AKI/SKI match
on unrelated certs is not a problem for us. I guess that
falls into category 3).

> In case there would be a followup to RFC 3280 my feeling is that
> increasing integers should be deprecated.

It's fine to deprecate this option (probably a
good idea), but we should also warn that AKI/SKI
may not match and that's fine. Nothing in RFC 3280
says this currently and that seems to be confusing
for implementors.

Thanks,

Steve Hanna


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LENLI7026436 for <[e-mail]>; Tue, 21 Oct 2003 07:23:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LENLPV026435 for ietf-pkix-bks; Tue, 21 Oct 2003 07:23:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LENKI7026430 for <[e-mail]>; Tue, 21 Oct 2003 07:23:20 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9LEM2xA001337; Tue, 21 Oct 2003 07:22:03 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h9LEM2B14799; Tue, 21 Oct 2003 10:22:02 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2003 10:21:31 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms276F0AA07F1B7F9D4A5D81DB"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms276F0AA07F1B7F9D4A5D81DB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A decent MUA would understand that there may be more
than one cert with the same SKI. AKI/SKI is just a
hint. As such, it's nice (maybe leading to better
performance) if there's one and only one cert with
a particular SKI. But it's not required.

In fact, if you use one of the key hash methods for
calculating the AKI/SKI and there are several certificates
with the same subject public key (as with multiple
cross-certificates for a single CA), these certificates
will probably all have the same SKI.

Note also that AKI/SKI chaining SHOULD NOT be checked
during path validation. To be more explicit, it's
NOT true that the SKI of a CA certificate must match
the AKI of a certificate signed by that CA. Why?
Because the CA certificate may have been issued by
a CA that uses a different AKI/SKI computation technique
than the CA who's the subject of the CA certificate.

Thanks,

Steve

Peter Gutmann wrote:
> 
> "Al Arsenault" <[e-mail]> writes:
> 
> >Why does an AKI/SKI have to be globally unique?
> >
> >It strikes me that the AKI/SKI extensions are simply "search aids".  That is,
> >they merely help the application (RP) determine which of a set of possible
> >certificates to use is the correct one. While it would be kind of cool if an
> >SKI/AKI would be globally unique (it would make searching a repository a
> >little easier/quicker IN SOME CASES), it doesn't strike me as a huge deal.
> 
>   You send me a CMS signed message (say) with the key identified by sKID = 0.
>   My MUA finds a cert with sKID = 0 and tries to verify the signature.  The
>   verification fails, and I get a warning saying that the forces of darkness
>   are tampering with my communications, I could be under attack, and the world
>   is about to end.
> 
>   You send me a CMS signed message (say) with the key identified by sKID =
>   aildhfsdfsjklhgdfjghkf.  My MUA can't find a cert with that sKID and
>   displays an informational message saying that it couldn't find a signing
>   key, and perhaps I should contact the sender for more information.
> 
> There's a big difference in terms of usability.
> 
> Peter.
--------------ms276F0AA07F1B7F9D4A5D81DB
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDMxMDIxMTQyMTMxWjAjBgkqhkiG9w0BCQQxFgQUv/TAMFGlDjV0//NsbjYbt3mS
m/wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCPScUS
79/iTTqCMhrz2al5L+i+UfQ63SO+8HBEHVPcL6rNEv4kVx/4cVr6m9L451HI+j+htUq5cA28
q4Otl+OLEa03zMx5gnd9JDXGK5EUTpiQmhkvBS61ItR+zjFuWb7+Lif4Cvuayi5rWwyeS9on
WGW7oDGVv6Tk+Dzi8A1/sQ==
--------------ms276F0AA07F1B7F9D4A5D81DB--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LEMBI7026393 for <[e-mail]>; Tue, 21 Oct 2003 07:22:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LEMBn5026392 for ietf-pkix-bks; Tue, 21 Oct 2003 07:22:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LEMAI7026386 for <[e-mail]>; Tue, 21 Oct 2003 07:22:10 -0700 (PDT) (envelope-from [e-mail])
Received: from arsenaultd2 (col-dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id h9LEL3TW028327; Tue, 21 Oct 2003 10:21:23 -0400 (EDT)
From: "Al Arsenault" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Tue, 21 Oct 2003 10:18:04 -0400
Message-ID: <[e-mail]>
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 V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well, bear in mind that RFC3280 allows the "monotonically increasing..." bit
only for CA certificates.  Section 4.2.1.2 explicitly says:

	" For end entity certificates, subject key identifiers SHOULD be
   derived from the public key.  Two common methods for generating key
   identifiers from the public key are identified above."

Okay, it's only a SHOULD, not a MUST, but the scenario you reference below
only comes in to play if I signed the CMS message using my CA cert, not my
end-entity cert.

Got an example where this is relevant if the sKID's of two different CA
certs are the same?  Granted, if I use the CA cert directly in an
application, problems like your example can occur, but such uses shouldn't
be happening (IMNSHO).

		Al Arsenault


-----Original Message-----
From: Peter Gutmann [mailto:[e-mail]]
Sent: Tuesday, October 21, 2003 9:10 AM
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Cc: [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?


"Al Arsenault" <[e-mail]> writes:

>Why does an AKI/SKI have to be globally unique?
>
>It strikes me that the AKI/SKI extensions are simply "search aids".  That
is,
>they merely help the application (RP) determine which of a set of possible
>certificates to use is the correct one. While it would be kind of cool if
an
>SKI/AKI would be globally unique (it would make searching a repository a
>little easier/quicker IN SOME CASES), it doesn't strike me as a huge deal.

  You send me a CMS signed message (say) with the key identified by sKID =
0.
  My MUA finds a cert with sKID = 0 and tries to verify the signature.  The
  verification fails, and I get a warning saying that the forces of darkness
  are tampering with my communications, I could be under attack, and the
world
  is about to end.

  You send me a CMS signed message (say) with the key identified by sKID =
  aildhfsdfsjklhgdfjghkf.  My MUA can't find a cert with that sKID and
  displays an informational message saying that it couldn't find a signing
  key, and perhaps I should contact the sender for more information.

There's a big difference in terms of usability.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LEAKI7025883 for <[e-mail]>; Tue, 21 Oct 2003 07:10:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LEAKbG025882 for ietf-pkix-bks; Tue, 21 Oct 2003 07:10:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LEAHI7025874 for <[e-mail]>; Tue, 21 Oct 2003 07:10:18 -0700 (PDT) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Oct 2003 15:10:09 +0100
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Oct 2003 15:10:09 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.45]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Oct 2003 15:10:09 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Tue, 21 Oct 2003 15:09:25 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AKI and SKI problem with RFC 3280?
Thread-Index: AcOX2cW85cVxQtaeS36/V6amFNEhyQAAIfFQ
From: "Stefan Santesson" <[e-mail]>
To: "Peter Hesse" <[e-mail]>, "Peter Gutmann" <[e-mail]>, <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 21 Oct 2003 14:10:09.0143 (UTC) FILETIME=[09058870:01C397DD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9LEAII7025877
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm particularly interested in the reality check.

If an application use AKI/SKI match to discover a path and finds an
AKI/SKI match of unrelated keys. What happens?

Ignoring what applications SHOULD do (which we all know)
What is in fact the current behaviour of applications today:

Do they:
1) Not even try to validate the path since issuer/subject don't match
2) Fail validation and display error
3) Fail validation, then goes back and search for another path


The danger with the outline of RFC 3280 is that two different methods
with different characteristics is proposed, while almost everybodey use
the first (key hash based). Implementers may thus be tempted to make
development shortcuts, based on a fair assumption that AKI/SKI match
indicates use of the same key, not causing any security risks, but
leading to unneccesary errors in casae that assumption is false.

In case there would be a followup to RFC 3280 my feeling is that
increasing integers should be deprecated. 

In the ETSI cert profile under development we are currently proposing to
deprecate this option.

/Stefan



 
> -----Original Message-----
> From: Peter Hesse [mailto:[e-mail]]
> Sent: den 21 oktober 2003 15:45
> To: 'Peter Gutmann'; [e-mail]; Stefan Santesson
> Cc: [e-mail]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> "Peter Gutmann" <[e-mail]> writes:
> 
> > My code has included a check to ignore the sKID if it's less than
> > 40 bits for some time now, because anything less than that is a
> > danger sign implying the use of an integer sequence.
> 
> The RFC 3280 certification path validation process does not include a
> check of the sKID and/or aKID; if they don't match, there is nothing
> wrong with the path.  Path building implementations should never rely
on
> them being correct.  They may be useful if they are present and
correct,
> but as was said, may lead building algorithms astray if they are
present
> and incorrect.  Therefore implementations should use them if they are
> helpful, but not rely on their existence or fail if they are
incorrect.
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    [e-mail]     |
> | Phone: [phone]         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been
> a statue set up in honor of a critic." --Jean Sibelius
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LE3aI7025700 for <[e-mail]>; Tue, 21 Oct 2003 07:03:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LE3aKw025699 for ietf-pkix-bks; Tue, 21 Oct 2003 07:03:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LE3ZI7025693 for <[e-mail]>; Tue, 21 Oct 2003 07:03:35 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.40] (dhcp89-089-040.bbn.com [128.89.89.40]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h9LE2iTX027344; Tue, 21 Oct 2003 10:03:05 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002002bbbaeb54a68f@[128.89.89.40]>
In-Reply-To:  <[e-mail].c om>
References:  <[e-mail].c om>
Date: Tue, 21 Oct 2003 10:00:43 -0400
To: "Stefan Santesson" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: AKI and SKI problem with RFC 3280?
Cc: <[e-mail]>, "Russ Housley" <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1145377522==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

At 11:12 +0100 10/20/03, Stefan Santesson wrote:
>
>I have come a cross a potential problem with RFC 3280 when working 
>on the new ETSI Certificate profile standard for identity certs.
>
>RFC 3280 states:
>
>4.2.1.1
>
>    The value of the keyIdentifier field SHOULD be derived from the
>    public key used to verify the certificate's signature or a method
>    that generates unique values.  Two common methods for generating key
>    identifiers from the public key, and one common method for generating
>    unique values, are described in section 4.2.1.2
>
>4.2.1.2
>    One common method for generating unique values is a monotonically
>    increasing sequence of integers.
>
>
>This means that a CA, following the recommendation can assign key 
>identifier values of e.g. 1, 2, 3, 4, 5, 6,..., n
>
>If many different CA:s would follow the "monotonically increasing 
>sequence of integers" procedure, multiple unrelated certificates 
>would end up having the same SKI and/or AKI values relating to 
>completely different public keys.
>
>I'm not sure how most path building clients would handle a situation 
>like that, but I fear that at least some would fail.
>
>Isn't the point that AKI:s and SKI:s should use a generation 
>algorithm that assigns them a globally unique value with high 
>probability and therefore SHOULD be derived from the public key and 
>NOT use a "monotonically increasing sequence of integers". At least 
>not starting from a small integer?
>
>/Stefan

For path building purposes, there is no need for uniqueness in these 
values.  We have stated several times that path building is NOT 
supposed to use these values to locate certs, but rather to 
disambiguate among certs that have the right Subject name (assuming a 
bottom's up path building).

However, when the SKI appears in an EE cert, and that EE cert is used 
in S/MIME, then we are assuming uniqueness, because the receiver uses 
the SKI to locate the right token for that receiver.  This support 
for S/MIME is why we put in the SKI requirement for EE certs, where 
it otherwise would not be needed (re path building).


Steve

P.S.  Peter, your example talked about signature verification, but I 
don't think that's right, because the signature info is not per 
recipient, it is per originator, and thus would not encounter this 
problem.
--============_-1145377522==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: AKI and SKI problem with RFC
3280?</title></head><body>
<div>At 11:12 +0100 10/20/03, Stefan Santesson wrote:</div>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">I have
come a cross a potential problem with RFC 3280 when working on the new
ETSI Certificate profile standard for identity
certs.</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">RFC
3280 states:</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">4.2.1.1</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;&nbsp; The value of the keyIdentifier field
SHOULD be derived from the</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;&nbsp; public key used to verify the
certificate's signature or</font><font color="#FF0000"> a
method</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#FF0000">&nbsp;&nbsp; that generates unique values</font><font
color="#000000">.&nbsp; Two common methods for generating
key</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;&nbsp; identifiers from the public
key,</font><font color="#FF0000"> and one common method for
generating</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#FF0000">&nbsp;&nbsp; unique values, are described in section
4.2.1.2</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">4.2.1.2</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;&nbsp;</font><font color="#FF0000"> One common
method for generating unique values is a
monotonically</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#FF0000">&nbsp;&nbsp; increasing sequence of
integers</font><font color="#000000">.</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">This means that a CA, following the recommendation can
assign key identifier values of e.g. 1, 2, 3, 4, 5, 6,...,
n</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">If many different CA:s would follow the
"</font><font color="#FF0000">monotonically increasing sequence of
integers</font><font color="#000000">" procedure, multiple unrelated
certificates would end up having the same SKI and/or AKI values
relating to completely different public keys.</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">I'm not sure how most path building clients would
handle a situation like that, but I fear that at least some would
fail.</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">Isn't the point that AKI:s and SKI:s should use a
generation algorithm that assigns them a globally unique value with
high probability and therefore SHOULD be derived from the public key
and NOT use a "</font><font color="#FF0000">monotonically increasing
sequence of integers</font><font color="#000000">". At least not
starting from a small integer?</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">/Stefan</font></blockquote>
<div><br></div>
<div>For path building purposes, there is no need for uniqueness in
these values.&nbsp; We have stated several times that path building is
NOT supposed to use these values to locate certs, but rather to
disambiguate among certs that have the right Subject name (assuming a
bottom's up path building).</div>
<div><br></div>
<div>However, when the SKI appears in an EE cert, and that EE cert is
used in S/MIME, then we are assuming uniqueness, because the receiver
uses the SKI to locate the right token for that receiver.&nbsp; This
support for S/MIME is why we put in the SKI requirement for EE certs,
where it otherwise would not be needed (re path building).</div>
<div><br></div>
<div><br></div>
<div>Steve</div>
<div><br></div>
<div>P.S.&nbsp; Peter, your example talked about signature
verification, but I don't think that's right, because the signature
info is not per recipient, it is per originator, and thus would not
encounter this problem.</div>
</body>
</html>
--============_-1145377522==_ma============--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LDkfI7025157 for <[e-mail]>; Tue, 21 Oct 2003 06:46:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LDkfsE025156 for ietf-pkix-bks; Tue, 21 Oct 2003 06:46:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LDkdI7025151 for <[e-mail]>; Tue, 21 Oct 2003 06:46:39 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA337414; Tue, 21 Oct 2003 09:46:24 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Tue, 21 Oct 2003 09:45:17 -0400
Organization: Gemini Security Solutions, Inc.
Message-ID: <007401c397d9$99078490$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Peter Gutmann" <[e-mail]> writes:

> My code has included a check to ignore the sKID if it's less than 
> 40 bits for some time now, because anything less than that is a 
> danger sign implying the use of an integer sequence.

The RFC 3280 certification path validation process does not include a
check of the sKID and/or aKID; if they don't match, there is nothing
wrong with the path.  Path building implementations should never rely on
them being correct.  They may be useful if they are present and correct,
but as was said, may lead building algorithms astray if they are present
and incorrect.  Therefore implementations should use them if they are
helpful, but not rely on their existence or fail if they are incorrect.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LDPRI7024523 for <[e-mail]>; Tue, 21 Oct 2003 06:25:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LDPROc024522 for ietf-pkix-bks; Tue, 21 Oct 2003 06:25:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LDPPI7024517 for <[e-mail]>; Tue, 21 Oct 2003 06:25:25 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9LDPPRS021484; Wed, 22 Oct 2003 02:25:25 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9LDQG308358; Wed, 22 Oct 2003 02:26:16 +1300
Date: Wed, 22 Oct 2003 02:26:16 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley <[e-mail]> writes:

>The only CA that I know about that did this has changed to a hash-based
>alternative.

There are European CAs that still do it AFAIK.  I have proof somewhere in the
cert menagerie :-).

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LDLqI7024452 for <[e-mail]>; Tue, 21 Oct 2003 06:21:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LDLqgx024451 for ietf-pkix-bks; Tue, 21 Oct 2003 06:21:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9LDLpI7024446 for <[e-mail]>; Tue, 21 Oct 2003 06:21:51 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 4141 invoked by uid 0); 21 Oct 2003 13:21:33 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (68.75.53.223) by woodstock.binhost.com with SMTP; 21 Oct 2003 13:21:33 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 21 Oct 2003 09:16:24 -0400
To: [e-mail], [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: AKI and SKI problem with RFC 3280?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

> >Isn't the point that AKI:s and SKI:s should use a generation algorithm that
> >assigns them a globally unique value with high probability and therefore
> >SHOULD be derived from the public key and NOT use a "monotonically 
> increasing
> >sequence of integers". At least not starting from a small integer?
>
>There is some reason why CAs do this, I can't remember why but I think it was
>the usual ostrich algorithm ("There is no CA but us; to think otherwise is
>treason punishable by limb reconstruction").  I'm not quite sure why the RFC
>tells you to do this though, since the only safe response to it is to ignore
>any sKIDs of that form.

The only CA that I know about that did this has changed to a hash-based 
alternative.

Russ



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LD9AI7023998 for <[e-mail]>; Tue, 21 Oct 2003 06:09:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LD9A6P023997 for ietf-pkix-bks; Tue, 21 Oct 2003 06:09:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LD98I7023991 for <[e-mail]>; Tue, 21 Oct 2003 06:09:09 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9LD8hRS021194; Wed, 22 Oct 2003 02:08:43 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9LD9YR08254; Wed, 22 Oct 2003 02:09:34 +1300
Date: Wed, 22 Oct 2003 02:09:34 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: AKI and SKI problem with RFC 3280?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Al Arsenault" <[e-mail]> writes:

>Why does an AKI/SKI have to be globally unique?
>
>It strikes me that the AKI/SKI extensions are simply "search aids".  That is,
>they merely help the application (RP) determine which of a set of possible
>certificates to use is the correct one. While it would be kind of cool if an
>SKI/AKI would be globally unique (it would make searching a repository a
>little easier/quicker IN SOME CASES), it doesn't strike me as a huge deal.

  You send me a CMS signed message (say) with the key identified by sKID = 0.
  My MUA finds a cert with sKID = 0 and tries to verify the signature.  The
  verification fails, and I get a warning saying that the forces of darkness
  are tampering with my communications, I could be under attack, and the world
  is about to end.

  You send me a CMS signed message (say) with the key identified by sKID =
  aildhfsdfsjklhgdfjghkf.  My MUA can't find a cert with that sKID and
  displays an informational message saying that it couldn't find a signing
  key, and perhaps I should contact the sender for more information.

There's a big difference in terms of usability.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LCfvI7023194 for <[e-mail]>; Tue, 21 Oct 2003 05:41:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LCfuUN023193 for ietf-pkix-bks; Tue, 21 Oct 2003 05:41:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LCfrI7023185 for <[e-mail]>; Tue, 21 Oct 2003 05:41:54 -0700 (PDT) (envelope-from [e-mail])
Received: from arsenaultd2 (col-dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id h9LCffTW023652; Tue, 21 Oct 2003 08:41:42 -0400 (EDT)
From: "Al Arsenault" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Tue, 21 Oct 2003 08:38:43 -0400
Message-ID: <[e-mail]>
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 V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Okay, I'll bite...

Why does an AKI/SKI have to be globally unique?

It strikes me that the AKI/SKI extensions are simply "search aids".  That
is, they merely help the application (RP) determine which of a set of
possible certificates to use is the correct one. While it would be kind of
cool if an SKI/AKI would be globally unique (it would make searching a
repository a little easier/quicker IN SOME CASES), it doesn't strike me as a
huge deal.

Even using the "monotonically increasing integer sequence" scheme, what we'd
have is:

	Cert A and Cert B have the same AKI value
	Cert A is issued by CA Z, and has serial number N
	Cert B is issued by CA Y, and has serial number M

	(Note that the CA values would be different, because a single CA can't
issue the same AKI/SKI value to multiple certs.  The serial numbers could
coincidentally be the same; that's a random chance.)

	So the path validation software SHOULD say:  "gee, I fetched a cert from
the repository by matching on SKI - I didn't bother searching on issuer
name/serial, or subject name, or...  So now I've got two matches.  Which one
should I use?  Maybe I should actually try looking at one of the other
fields to get a clue, or maybe I'll just take a shot and die a horrible
screaming death if I guess wrong?"

	I'm foggy on the details, but it strikes me that the "monotonically
increasing integer" scheme was actually in use by somebody, and nobody
believed it was a real problem, given the use of the extensions, so we said,
in essence, "heck, why not?" How has that changed?

				Al Arsenault


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Peter Gutmann
Sent: Tuesday, October 21, 2003 2:03 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?



"Stefan Santesson" <[e-mail]> writes:

@microsoft.com?

>If many different CA:s would follow the "monotonically increasing sequence
of
>integers" procedure, multiple unrelated certificates would end up having
the
>same SKI and/or AKI values relating to completely different public keys.

Yup.  I've seen CAs use bits of key hashes, monotonically increasing
integers,
numeric text strings, MPEGs of cats...

>I'm not sure how most path building clients would handle a situation like
>that, but I fear that at least some would fail.

My code has included a check to ignore the sKID if it's less than 40 bits
for
some time now, because anything less than that is a danger sign implying the
use of an integer sequence.

>Isn't the point that AKI:s and SKI:s should use a generation algorithm that
>assigns them a globally unique value with high probability and therefore
>SHOULD be derived from the public key and NOT use a "monotonically
increasing
>sequence of integers". At least not starting from a small integer?

There is some reason why CAs do this, I can't remember why but I think it
was
the usual ostrich algorithm ("There is no CA but us; to think otherwise is
treason punishable by limb reconstruction").  I'm not quite sure why the RFC
tells you to do this though, since the only safe response to it is to ignore
any sKIDs of that form.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9L623I7041777 for <[e-mail]>; Mon, 20 Oct 2003 23:02:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9L6236I041776 for ietf-pkix-bks; Mon, 20 Oct 2003 23:02:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9L621I7041742 for <[e-mail]>; Mon, 20 Oct 2003 23:02:02 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9L622RS012257; Tue, 21 Oct 2003 19:02:02 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9L62ml03348; Tue, 21 Oct 2003 19:02:48 +1300
Date: Tue, 21 Oct 2003 19:02:48 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: AKI and SKI problem with RFC 3280?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Stefan Santesson" <[e-mail]> writes:

@microsoft.com?

>If many different CA:s would follow the "monotonically increasing sequence of
>integers" procedure, multiple unrelated certificates would end up having the
>same SKI and/or AKI values relating to completely different public keys.

Yup.  I've seen CAs use bits of key hashes, monotonically increasing integers,
numeric text strings, MPEGs of cats...

>I'm not sure how most path building clients would handle a situation like
>that, but I fear that at least some would fail.

My code has included a check to ignore the sKID if it's less than 40 bits for
some time now, because anything less than that is a danger sign implying the
use of an integer sequence.

>Isn't the point that AKI:s and SKI:s should use a generation algorithm that
>assigns them a globally unique value with high probability and therefore
>SHOULD be derived from the public key and NOT use a "monotonically increasing
>sequence of integers". At least not starting from a small integer?

There is some reason why CAs do this, I can't remember why but I think it was
the usual ostrich algorithm ("There is no CA but us; to think otherwise is
treason punishable by limb reconstruction").  I'm not quite sure why the RFC
tells you to do this though, since the only safe response to it is to ignore
any sKIDs of that form.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KAI0I7086013 for <[e-mail]>; Mon, 20 Oct 2003 03:18:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KAI07G086012 for ietf-pkix-bks; Mon, 20 Oct 2003 03:18:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [212.157.154.44]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KAHtI7086003 for <[e-mail]>; Mon, 20 Oct 2003 03:17:56 -0700 (PDT) (envelope-from [e-mail])
Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 20 Oct 2003 12:17:46 +0200
Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Oct 2003 12:17:22 +0200
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 20 Oct 2003 12:14:00 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: AKI and SKI problem with RFC 3280?
Date: Mon, 20 Oct 2003 11:12:24 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AKI and SKI problem with RFC 3280?
thread-index: AcOVwjxQcsDRGefpR+yZ6uNiHYuRwgBLcWZQ
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Cc: "Russ Housley" <[e-mail]>
X-OriginalArrivalTime: 20 Oct 2003 10:14:00.0552 (UTC) FILETIME=[E1785E80:01C396F2]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C396F2.E09683D7"

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

=20

I have come a cross a potential problem with RFC 3280 when working on
the new ETSI Certificate profile standard for identity certs.

=20

RFC 3280 states:

=20

4.2.1.1

=20

   The value of the keyIdentifier field SHOULD be derived from the

   public key used to verify the certificate's signature or a method

   that generates unique values.  Two common methods for generating key

   identifiers from the public key, and one common method for generating

   unique values, are described in section 4.2.1.2

=20

4.2.1.2

   One common method for generating unique values is a monotonically

   increasing sequence of integers.

=20

=20

This means that a CA, following the recommendation can assign key
identifier values of e.g. 1, 2, 3, 4, 5, 6,..., n

=20

If many different CA:s would follow the "monotonically increasing
sequence of integers" procedure, multiple unrelated certificates would
end up having the same SKI and/or AKI values relating to completely
different public keys.

=20

I'm not sure how most path building clients would handle a situation
like that, but I fear that at least some would fail.

=20

Isn't the point that AKI:s and SKI:s should use a generation algorithm
that assigns them a globally unique value with high probability and
therefore SHOULD be derived from the public key and NOT use a
"monotonically increasing sequence of integers". At least not starting
from a small integer?

=20

/Stefan


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

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 77.95pt 70.85pt 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DSV
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I have come a cross a potential problem with RFC 3280 when =
working on the
new ETSI Certificate profile standard for identity =
certs.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>RFC 3280 states:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>4.2.1.1<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; The value of the
keyIdentifier field SHOULD be derived from =
the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; public key used to =
verify the
certificate's signature or </span></font><font color=3Dred><span
style=3D'color:red'>a method<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dred face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:red'>&nbsp;&nbsp; that generates unique =
values</span></font><font
color=3Dblack><span style=3D'color:black'>.&nbsp; Two common methods for =
generating
key<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; identifiers from the =
public
key, </span></font><font color=3Dred><span style=3D'color:red'>and one =
common
method for generating<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dred face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:red'>&nbsp;&nbsp; unique values, are =
described in
section 4.2.1.2</span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=
>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>4.2.1.2<o:p></o:p></span></font></=
p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; </span></font><font
color=3Dred><span style=3D'color:red'>One common method for generating =
unique
values is a monotonically<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dred face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:red'>&nbsp;&nbsp; increasing sequence of =
integers</span></font><font
color=3Dblack><span style=3D'color:black'>.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=
>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=
>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>This means that a CA, following =
the
recommendation can assign key identifier values of e.g. 1, 2, 3, 4, 5, =
6,..., n<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=
>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>If many different CA:s would =
follow the &#8220;</span></font><font
color=3Dred><span style=3D'color:red'>monotonically increasing sequence =
of integers</span></font><font
color=3Dblack><span style=3D'color:black'>&#8220; procedure, multiple =
unrelated certificates
would end up having the same SKI and/or AKI values relating to =
completely
different public keys.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=
>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>I&#8217;m not sure how most path =
building clients
would handle a situation like that, but I fear that at least some would =
fail.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=
>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>Isn&#8217;t the point that AKI:s =
and SKI:s
should use a generation algorithm that assigns them a globally unique =
value
with high probability and therefore SHOULD be derived from the public =
key and
NOT use a &#8220;</span></font><font color=3Dred><span =
style=3D'color:red'>monotonically
increasing sequence of integers</span></font><font color=3Dblack><span
style=3D'color:black'>&#8220;. At least not starting from a small =
integer?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=
>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>/Stefan<o:p></o:p></span></font></=
p>

</div>

</body>

</html>

------_=_NextPart_001_01C396F2.E09683D7--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9J2nTI7040459 for <[e-mail]>; Sat, 18 Oct 2003 19:49:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9J2nTOx040458 for ietf-pkix-bks; Sat, 18 Oct 2003 19:49:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9J2nTI7040453 for <[e-mail]>; Sat, 18 Oct 2003 19:49:29 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc12) with ESMTP id <20031019024926014007493se>; Sun, 19 Oct 2003 02:49:26 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1AB3dU-0000iq-00; Sat, 18 Oct 2003 22:49:40 -0400
Message-ID: <[e-mail]>
Date: Sat, 18 Oct 2003 22:49:39 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: DISCUSSION: Nonce-specific error code for OCSP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry, didn't mean to start a rehash of the original nonce argument.
My original point was in response to precise protocol assertion from 
Mike's last email:

     Further, the requestor which sent a nonce and received a
     non-nonced response can today infer "responder does not support
     nonces."

I was basically trying to say that, at a protocol level, this statement 
is false.

If a client sends a request to a responder that includes a nonce, and 
that client receives either:
    (a) an unsigned OCSPResponseStatus
     - or -
    (b) a signed response with no nonce and no special extensions
then that client has no way to tell whether that OCSP responder is 
intentionally configured to ignore nonces, or whether an attacker on the 
network is providing (a) bogus or (b) replayed information.

If the signed body of the response contains an extension that says "this 
OCSP infrastructure never provides nonces for any requests", then the 
client can securely determine that this declaration came from a trusted 
entity (the OCSP signer) and not an intermediate attacker.



> The requirement is to bind a request to its associated response
> and thus enable relying parties to mitigate replay risks.  I
> remain curious to an understanding of how unilateral server-side
> response extensions achieve this effect.

I disagree.  The real requirement is that the certificate status 
response be as provably up-to-date as possible for a given request.  All 
this "binding" stuff is just a particular mechanism which MAY achieve 
that requirement.

A nonce can be used to strongly bind a response to a specific request. 
This proves that the response is "fresh" from a responder.  This MAY 
give indication that the underlying status information is up-to-date. 
If, however, the response was provided by a responder which is using a 
CRL that is 11 hours old, the nonce is only providing me with the 
illusion of immediacy.  If a cert was revoked 6 hours ago, that 
responder will provide "fresh" responses validating that cert until the 
next CRL is released and processed.

A response based on a start time (thisUpdate) and end time (nextUpdate) 
more accurately reflects the real underlying status information in any 
system with responders using periodic CRLs.



> In the instance of explicit delegation from a certification
> authority, there then exists a business entity which places
> itself in a position of risk against damage claims.  Are you
> suggesting that an OCSP responder's unilateral inclusion of a
> technical artifact is an assertion of willingness to absorb such
> risks?

Oh, I don't think that lawyers would be quite as clear on the liability 
distinction between ACME Novelty's CA and its Responders.  In both 
cases, ACME has IT personnel running servers with HSMs that provide 
digitally signed information attesting to the identity and status of 
ACME employees.  I don't think you'd avoid any lawsuits by asserting 
that a revoked certificate was "validated" using a compromised ACME OCSP 
Responder rather than a bad CRL from a compromised ACME CA.

But I certainly wouldn't advocate any sort of unilateral inclusion of 
technical artifacts ... that's why we're discussing this as part of the 
standards process.

Thanks,
Dave



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9J1BQI7036933 for <[e-mail]>; Sat, 18 Oct 2003 18:11:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9J1BPSp036932 for ietf-pkix-bks; Sat, 18 Oct 2003 18:11:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9J1BOI7036925 for <[e-mail]>; Sat, 18 Oct 2003 18:11:24 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h9J1BPt76436; Sat, 18 Oct 2003 18:11:25 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 18:14:26 -0700
Message-ID: <[e-mail]>
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)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

A few thoughts embedded below.

Mike

> -----Original Message-----
> From: David Engberg
>
> . . .
>
> An existing client can't tell the difference between a
> server that doesn't support nonces and a replay
> attack by an attacker who made a nonceless request.
> An explicit "nonceUnsupported" extension in the signed
> body of the response allows a client to securely tell the
> difference between these cases.


The requirement is to bind a request to its associated response
and thus enable relying parties to mitigate replay risks.  I
remain curious to an understanding of how unilateral server-side
response extensions achieve this effect.


> OCSP and other PKIX standards currently allow some
> policy decisions to be made by the infrastructure
> authorities (CAs, responders) and others by the
> relying parties.  For example, the pkix-nocheck
> extension allows the infrastructure to tell clients
> that they should accept a delegated responder cert
> without performing validation.  This extension was
> approved, even though someone could have made an
> argument that "only clients should be allowed to
> set responder validation policies."


In the instance of explicit delegation from a certification
authority, there then exists a business entity which places
itself in a position of risk against damage claims.  Are you
suggesting that an OCSP responder's unilateral inclusion of a
technical artifact is an assertion of willingness to absorb such
risks?

Bear in mind that the relying party problem is notoriously
difficult.  It only appears in the heterogeneous context we are
now debating; else contracts suffice.  If you are unfamiliar
with the issue, you may wish to consult with our legal peers in
the American Bar Association's Information Security Committee.


> Something like "nonceUnsupported" would fall in the
> same category ... the infrastructure is telling
> interested clients about the security characteristics
> of that PK infrastructure and suggesting a security
> policy based on that information.


Infrastructure should serve the needs of its participants rather
than the other way around.

Mike
[phone]




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9INdJI7034927 for <[e-mail]>; Sat, 18 Oct 2003 16:39:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9INdJMd034926 for ietf-pkix-bks; Sat, 18 Oct 2003 16:39:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9INdII7034918 for <[e-mail]>; Sat, 18 Oct 2003 16:39:18 -0700 (PDT) (envelope-from [e-mail])
Received: from netserver (12-234-48-248.client.attbi.com[12.234.48.248]) by comcast.net (rwcrmhc13) with SMTP id <2003101823391501500dmah4e>; Sat, 18 Oct 2003 23:39:15 +0000
Message-ID: <006501c395d1$499e4b00$[e-mail]>
From: "Piyush" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 16:41:00 -0700
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

NO.

Piyush
----- Original Message ----- 
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, October 15, 2003 2:02 PM
Subject: POLL: Nonce-specific error code for OCSP


> 
> All,
> 
> I recently received permission from the chairs to poll the WG
> against the following question.
> 
> Should we standardize an OCSP *V1* error code that enables a
> responder to indicate its inability to respond to nonced
> requests?
> 
> Please respond with either YES or NO.
> 
> Mike
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IKEFI7030020 for <[e-mail]>; Sat, 18 Oct 2003 13:14:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IKEF75030019 for ietf-pkix-bks; Sat, 18 Oct 2003 13:14:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IKEFI7030008 for <[e-mail]>; Sat, 18 Oct 2003 13:14:15 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc12) with ESMTP id <200310182014110140074kv2e>; Sat, 18 Oct 2003 20:14:11 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1AAxSy-0000FU-00; Sat, 18 Oct 2003 16:14:24 -0400
Message-ID: <[e-mail]>
Date: Sat, 18 Oct 2003 16:14:23 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: DISCUSSION: Nonce-specific error code for OCSP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Myers wrote:

> Further, the requestor which sent a nonce and received a
> non-nonced response can today infer "responder does not support
> nonces."  Something like 11 of 12 client side implementors claim
> ability to detect such.  Inclusion of an extension which in
> effect asserts that "I as responder give myself permission to
> disregard your nonce" does nothing to improve upon that.


I believe that it is not currently possible to infer this under the 
current spec.  An existing client can't tell the difference between a 
server that doesn't support nonces and a replay attack by an attacker 
who made a nonceless request.  An explicit "nonceUnsupported" extension 
in the signed body of the response allows a client to securely tell the 
difference between these cases.

OCSP and other PKIX standards currently allow some policy decisions to 
be made by the infrastructure authorities (CAs, responders) and others 
by the relying parties.  For example, the pkix-nocheck extension allows 
the infrastructure to tell clients that they should accept a delegated 
responder cert without performing validation.  This extension was 
approved, even though someone could have made an argument that "only 
clients should be allowed to set responder validation policies."

Something like "nonceUnsupported" would fall in the same category ... 
the infrastructure is telling interested clients about the security 
characteristics of that PK infrastructure and suggesting a security 
policy based on that information.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IHnsI7025624 for <[e-mail]>; Sat, 18 Oct 2003 10:49:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IHns2w025623 for ietf-pkix-bks; Sat, 18 Oct 2003 10:49:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IHnnI7025612 for <[e-mail]>; Sat, 18 Oct 2003 10:49:52 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd04.aul.t-online.de  by mailout07.sul.t-online.com with smtp  id 1AAvCq-0002U5-07; Sat, 18 Oct 2003 19:49:36 +0200
Received: from hagen (GQVxR6ZU8eDjMs8StLb-L3DjN-eDDaug0+KoryqDXMcCEsHThb3Tk5@[80.128.92.191]) by fmrl04.sul.t-online.com with esmtp id 1AAvCe-0h9Ioq0; Sat, 18 Oct 2003 19:49:24 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "'David Engberg'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 19:49:23 +0200
Organization: SyTrust
Message-ID: <000901c395a0$2ade3ee0$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> It seems to me that an extended response is no improvement 
> upon a plain response when applied to replay detection.  It 
> too can be replayed because there is no dynamic binding 
> between request and response.  That's what the nonce 
> extension was defined to
> enable: client-side elimination of replay risks via dynamic binding.

The response can be replayed. Thats true. But the client now has a way
of dectecting if the responder supports nonces. So the client will ask
itself: Why should I accept a response without nonce from a responder
that supports nonce? Coming to the conclusion that something is wrong
the client can now disregard the response.

Today, when a client sends a request with nonce and gets a response
without nonce that can mean:

A) the responder does not support nonces
B) the responder would support nonces but this is a replay (the attacker
is replaying the response to a request without nonce)

With either one of the proposed extensions, the client would get a
secure method of differentiation between these two cases.

Imagine an attacker now recording an OCSP response to a request without
nonce and replaying this response to another request with nonce. With
the proposed extensions, the replayed response contains information
saying that this responder usually supports nonces. Thus the client will
reject the response, as it did not contain a nonce but the responder
simultaneous indicates that it would support nonce generation.

> Further, the requestor which sent a nonce and received a 
> non-nonced response can today infer "responder does not 
> support nonces."  Something like 11 of 12 client side 
> implementors claim ability to detect such.  Inclusion of an 
> extension which in effect asserts that "I as responder give 
> myself permission to disregard your nonce" does nothing to 
> improve upon that.

I know that 11 of 12 client side implementors think they can infer such
a conclusion. But - sad to say - this conclusion is not necessarily true
in the current state of RfC2560. The response could also be a replay of
a response to a request without nonce. Thats why we need the extension
(or server-generated nonces as a work-around).

So the inclusion of an extension saying that "I AS RESPONDER give myself
permission to disregard your nonce" has a real value. It indicates that
the responder KNOWS that this response may be used in replay or caching
situations. It is a lot better than the current situation. Currently a
response without nonce asserts that "I as responder OR ATTACKER give
myself permission to disregard your nonce".

I hope that clarifies why we want something to the effect of this
proposal so urgently.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IHM1I7024690 for <[e-mail]>; Sat, 18 Oct 2003 10:22:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IHM1LA024689 for ietf-pkix-bks; Sat, 18 Oct 2003 10:22:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IHLsI7024681 for <[e-mail]>; Sat, 18 Oct 2003 10:21:59 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h9IHLpt44835; Sat, 18 Oct 2003 10:21:51 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "'David Engberg'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 10:24:51 -0700
Message-ID: <[e-mail]>
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: <000001c39565$69ee5b50$4228a8c0@hagen>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It seems to me that an extended response is no improvement upon
a plain response when applied to replay detection.  It too can
be replayed because there is no dynamic binding between request
and response.  That's what the nonce extension was defined to
enable: client-side elimination of replay risks via dynamic
binding.

Further, the requestor which sent a nonce and received a
non-nonced response can today infer "responder does not support
nonces."  Something like 11 of 12 client side implementors claim
ability to detect such.  Inclusion of an extension which in
effect asserts that "I as responder give myself permission to
disregard your nonce" does nothing to improve upon that.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IDNSI7018885 for <[e-mail]>; Sat, 18 Oct 2003 06:23:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IDNSwT018884 for ietf-pkix-bks; Sat, 18 Oct 2003 06:23:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IDNRI7018879 for <[e-mail]>; Sat, 18 Oct 2003 06:23:28 -0700 (PDT) (envelope-from [e-mail])
Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id h9IDNSKj001157 for <[e-mail]>; Sat, 18 Oct 2003 09:23:28 -0400
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Subject: new WG
Date: Sat, 18 Oct 2003 09:23:22 -0400
Message-ID: <002d01c3957b$04414bd0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C39559.7D2FABD0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

A new working group is being formed to address long-term archive and notary
services.  Mailing list information can be found at
http://www.imc.org/ietf-ltans/index.html; additional details can be found
at: http://ltans.edelweb.fr.  We'll be meeting for the first time at the
upcoming IETF meeting in Minneapolis.  Anyone interested in giving a
presentation during the WG session should send a request to
[e-mail] or [e-mail].

------=_NextPart_000_002E_01C39559.7D2FABD0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D774390113-18102003><FONT face=3DArial size=3D2>A new =
working group=20
is being&nbsp;formed&nbsp;to address long-term archive and notary=20
services.&nbsp; Mailing list information can be found at <A=20
href=3D"http://www.imc.org/ietf-ltans/index.html">http://www.imc.org/ietf=
-ltans/index.html</A>;=20
additional details can be found at: <A=20
href=3D"http://ltans.edelweb.fr">http://ltans.edelweb.fr</A>.&nbsp; =
We'll be=20
meeting for the first time at the upcoming IETF meeting in =
Minneapolis.&nbsp;=20
Anyone interested in giving a presentation during the WG session should =
send a=20
request to&nbsp;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&nbsp;or=
 <A=20
href=3D"mailto:[e-mail]">[e-mail]</A>.</FONT></=
SPAN></DIV></BODY></HTML>

------=_NextPart_000_002E_01C39559.7D2FABD0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IAqVI7012177 for <[e-mail]>; Sat, 18 Oct 2003 03:52:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IAqVOh012176 for ietf-pkix-bks; Sat, 18 Oct 2003 03:52:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IAqTI7012171 for <[e-mail]>; Sat, 18 Oct 2003 03:52:30 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd04.aul.t-online.de  by mailout05.sul.t-online.com with smtp  id 1AAoh0-0005ly-01; Sat, 18 Oct 2003 12:52:18 +0200
Received: from hagen (VgaSraZSZeEshxY5S8DyZc+8Cnzqumh2rD+A5PUL8gisdioAtyt7s4@[80.128.92.191]) by fmrl04.sul.t-online.com with esmtp id 1AAogr-0PUK4O0; Sat, 18 Oct 2003 12:52:09 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, <[e-mail]>
Cc: "'David Engberg'" <[e-mail]>, "'Alex Deacon'" <[e-mail]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 12:52:06 +0200
Organization: SyTrust
Message-ID: <000101c39565$df858190$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Because willful disregard of a client's nonce violates first 
> principles.  Enabling service providers a legal basis to do 
> so via reliance on an IETF standard is a whole different question.

It is not a "willful disregard"! A caching responder CANNOT answer
nonces. 

And the IETF standard already defines a "legal basis" for a service
provide to do so: simply not answering the nonce. Thats not a perfect
way - but thats the way RfC2560 suggests.

Can you please tell me where those "first principles" of the IETF you
mention are defined? Where can I read more about it? What "first
principles" do you mean exactly?

Thanks for your help,

-- 
Florian Oelmaier
SyTrust




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IAn7I7011931 for <[e-mail]>; Sat, 18 Oct 2003 03:49:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IAn7Pw011930 for ietf-pkix-bks; Sat, 18 Oct 2003 03:49:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IAn5I7011924 for <[e-mail]>; Sat, 18 Oct 2003 03:49:06 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd04.aul.t-online.de  by mailout09.sul.t-online.com with smtp  id 1AAodr-0000qV-00; Sat, 18 Oct 2003 12:49:03 +0200
Received: from hagen (EkzUhTZ1ge6JE7tBpjmeDiWuVyRWe+hUKqbkkMSUoqmvsi-n3cTxUe@[80.128.92.191]) by fmrl04.sul.t-online.com with esmtp id 1AAodg-1m2rUO0; Sat, 18 Oct 2003 12:48:52 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'David Engberg'" <[e-mail]>, "'Michael Myers'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 12:48:49 +0200
Organization: SyTrust
Message-ID: <000001c39565$69ee5b50$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Engberg wrote:
> Dumb question:  why is it possible to add a new 
> OCSPResponseStatus code 
> value (a non-backward-compatible addition) for v1, but not to convey 
> this information through a new responseExtension in the 
> signed body (a 
> backward compatible change with better security semantics)?

/agree

Even more as all extension procressing is optional, meaning that such an
addition IS completely backward compatible with all clients out there by
definiton. Why did we add the extension system in the first place? I
thought this was done with such extensions in mind.

After all this discussion, we have two options for adding such an
extension:



Option A) "The-signer-of-this-response-intended-it-to-be-cached
extension": Even when the request containes a nonce a responder may
answer with a response containing no nonce but this extension.

Clients supporting nonces should not accept a nonce-less response
without this extension.



Option B) "Usually-I-support-nonce extension": Responders that are able
to generate nonces and get a request without nonce add this extension.
(A responder could also indicate this by producing a server-generated
nonce). 

Clients supporting nonces should not accept responses containing this
extension but NOT containing a fitting nonce. Getting a response without
nonce and without this extension indicates, that the responder is not
able to generate nonces.



Mind: These options do basically the same, we only need one of them.



I strongly vote to include an extension according option A (Davids
proposal) into OCSPv1. 

If this is not possible, I would like to advise all responder
implementers to use Option B with server-generated nonces, as this
behaviour is already covered by OCSPv1 and does not need any changes to
the RfC. For OCSPv2 we should then go for an extension according to
option A.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9I14QI7031801 for <[e-mail]>; Fri, 17 Oct 2003 18:04:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9I14Qdm031800 for ietf-pkix-bks; Fri, 17 Oct 2003 18:04:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from infoblox.com (trevise.infoblox.com [209.209.39.217]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9I14OI7031794 for <[e-mail]>; Fri, 17 Oct 2003 18:04:24 -0700 (PDT) (envelope-from [e-mail])
Received: from DICK (205.158.171.194.ptr.us.xo.net [205.158.171.194]) by infoblox.com (Postfix) with SMTP id B91C9544C0; Fri, 17 Oct 2003 18:04:26 -0700 (PDT)
Message-ID: <002a01c39513$b7112fe0$[e-mail]>
From: "Richard Sinn (Infoblox)" <[e-mail]>
To: "Miguel Rodriguez" <[e-mail]>, "'Michael Myers'" <[e-mail]>
Cc: <[e-mail]>
References: <001701c394b4$c71ee260$[e-mail]>
Subject: Re: POLL: Nonce-specific error code for OCSP
Date: Fri, 17 Oct 2003 18:03:59 -0700
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

NO. 

Clearly after all these discussion. 

- Richard.

----- Original Message ----- 
From: "Miguel Rodriguez" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, October 17, 2003 6:44 AM
Subject: RE: POLL: Nonce-specific error code for OCSP


> 
> NO
> 
> Miguel A Rodriguez
> SeguriDATA
> Mexico
> 
> > 
> > This poll is focussed on the narrower v1 issue ONLY. Should we
> > or should we not standardize a v1 error code? If this poll is
> > inconclusive, then I suppose we'll get into the heart of the
> > matter, which is whether it is acceptable in v1 to disregard a
> > client's nonce.  But let's leave those discussions to another
> > thread and first get a vote tally.
> > 
> > Mike
> > 
> 
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HMo1I7028835 for <[e-mail]>; Fri, 17 Oct 2003 15:50:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HMo1hP028834 for ietf-pkix-bks; Fri, 17 Oct 2003 15:50:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HMo0I7028825 for <[e-mail]>; Fri, 17 Oct 2003 15:50:00 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h9HMo2t47044; Fri, 17 Oct 2003 15:50:02 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "David Engberg" <[e-mail]>, "Alex Deacon" <[e-mail]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Fri, 17 Oct 2003 15:53:02 -0700
Message-ID: <[e-mail]>
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Because willful disregard of a client's nonce violates first
principles.  Enabling service providers a legal basis to do so
via reliance on an IETF standard is a whole different question.

Mike


> -----Original Message-----
> From: David Engberg [mailto:[e-mail]]
> Sent: Friday, October 17, 2003 2:26 PM
> To: Michael Myers
> Cc: [e-mail]
> Subject: DISCUSSION: Nonce-specific error code for OCSP
>
>
>
> Dumb question:  why is it possible to add a new
> OCSPResponseStatus code value (a non-backward-
> compatible addition) for v1, but not to convey
> this information through a new responseExtension in
> the signed body (a backward compatible change with
> better security semantics)?




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HLQdI7026446 for <[e-mail]>; Fri, 17 Oct 2003 14:26:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HLQd6w026445 for ietf-pkix-bks; Fri, 17 Oct 2003 14:26:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HLQcI7026433 for <[e-mail]>; Fri, 17 Oct 2003 14:26:38 -0700 (PDT) (envelope-from [e-mail])
Received: from corestreet.com (engberg2.corestreet.com [192.168.2.119]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id h9HLQSxh018929; Fri, 17 Oct 2003 17:26:28 -0400
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2003 17:26:28 -0400
From: David Engberg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: DISCUSSION: Nonce-specific error code for OCSP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dumb question:  why is it possible to add a new OCSPResponseStatus code 
value (a non-backward-compatible addition) for v1, but not to convey 
this information through a new responseExtension in the signed body (a 
backward compatible change with better security semantics)?





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HDibI7010579 for <[e-mail]>; Fri, 17 Oct 2003 06:44:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HDibgu010578 for ietf-pkix-bks; Fri, 17 Oct 2003 06:44:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HDiZI7010569 for <[e-mail]>; Fri, 17 Oct 2003 06:44:36 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Oct 2003 08:45:35 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Fri, 17 Oct 2003 08:44:19 -0500
Message-ID: <001701c394b4$c71ee260$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 17 Oct 2003 13:45:35.0156 (UTC) FILETIME=[F0CDF740:01C394B4]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

NO

Miguel A Rodriguez
SeguriDATA
Mexico

> 
> This poll is focussed on the narrower v1 issue ONLY. Should we
> or should we not standardize a v1 error code? If this poll is
> inconclusive, then I suppose we'll get into the heart of the
> matter, which is whether it is acceptable in v1 to disregard a
> client's nonce.  But let's leave those discussions to another
> thread and first get a vote tally.
> 
> Mike
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H6HQI7048895 for <[e-mail]>; Thu, 16 Oct 2003 23:17:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9H6HQgl048893 for ietf-pkix-bks; Thu, 16 Oct 2003 23:17:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ddba033.netstream.ch (ddba033.netstream.ch [62.65.128.33]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H6HOI7048833 for <[e-mail]>; Thu, 16 Oct 2003 23:17:25 -0700 (PDT) (envelope-from [e-mail])
Received: from [62.65.151.222] (helo=laptopjad) by ddba033.netstream.ch with esmtp (Exim 4.10) id 1AANvN-000LEj-00; Fri, 17 Oct 2003 08:17:21 +0200
From: "Joseph A. Doekbrijder" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Fri, 17 Oct 2003 08:17:16 +0200
Organization: SwissSign
Message-ID: <001201c39476$508c9c70$2103a8c0@laptopjad>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9H6HPI7048883
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No.

Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: [phone]
Mobile: [phone]
www.swisssign.com
--------------------------------------------------

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Michael Myers
> Sent: Thursday, October 16, 2003 18:05
> To: [e-mail]
> Subject: RE: POLL: Nonce-specific error code for OCSP
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]On Behalf Of Denis Pinkas
> > Sent: Thursday, October 16, 2003 12:34 AM
> > To: Michael Myers
> > Cc: [e-mail]
> > Subject: Re: POLL: Nonce-specific error code for OCSP
> >
> >
> >
> > Mike,
> >
> > > All,
> >
> > > I recently received permission from the chairs to
> > poll the WG
> > > against the following question.
> >
> > > Should we standardize an OCSP *V1* error code that enables a 
> > > responder to indicate its inability to respond to nonced requests?
> >
> > > Please respond with either YES or NO.
> >
> > I would suggest to you provide a resumé of the
> > advantages of this new error
> > code (and disadvantages if not supported), so that
> > people do not have to
> > look back at that long thread on that topic to make
> > up their opinion.
> >
> > Denis
> >
> > > Mike
> 
> 
> 
> A reasonable request.
> 
> In summary, we need to standardize the treatment of nonces 
> when nonces aren't supported.  RFC2560 is regrettably silent 
> on the point.  The need to do so is particularly acute in the 
> context of heterogeneous populations of clients and servers 
> (i.e. not operating under a single administrative authority). 
>  Some may be set up to use or support nonces and some may 
> not.  The question is of course moot for requests that don't 
> contain nonces.
> 
> The issue is further complicated by the use of pre-produced 
> responses to achieve scalability through caching (i.e.
> non-signing) servers.  A relay back to a master signing 
> server could work, but that doesn't seem to be a popular 
> option.  So that leaves us with two server-side options.  
> Either: 1) send back a non-nonced response anyway with 
> technical extensions; or
> 2) send back an error code.
> 
> Variations on option 1 have been discussed, with the 
> likelihood that an extended response syntax or equivalent 
> technical mechanisms will force a v2 and all that entails 
> with regard to IETF process.
> 
> Yet we also need to do something sooner about v1.  In this 
> case, an existing error could be designated or we could 
> define a new one that servers can send back in the event they 
> don't support nonces.  Absent a designated error code, it is 
> predictable that ad-hoc selections will be made to to address 
> the issue with a consequent reduction in Internet-wide OCSP 
> interoperability and security.
> 
> This poll is focussed on the narrower v1 issue ONLY. Should 
> we or should we not standardize a v1 error code? If this poll 
> is inconclusive, then I suppose we'll get into the heart of 
> the matter, which is whether it is acceptable in v1 to 
> disregard a client's nonce.  But let's leave those 
> discussions to another thread and first get a vote tally.
> 
> Mike
> 
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H38uI7026364 for <[e-mail]>; Thu, 16 Oct 2003 20:08:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9H38uPd026362 for ietf-pkix-bks; Thu, 16 Oct 2003 20:08:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H38tI7026356 for <[e-mail]>; Thu, 16 Oct 2003 20:08:55 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h9H38vt95630 for <[e-mail]>; Thu, 16 Oct 2003 20:08:58 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: DISCUSS: Nonce-specific error code for OCSP
Date: Thu, 16 Oct 2003 20:12:01 -0700
Message-ID: <[e-mail]>
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-reply-to: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

Perhaps this time the subject line modification will stick.  Two
discussion points embedded below.  Apologies in advance for the
abbreviation of your thoughtful comments.

Mike


> -----Original Message-----
> From: Julien Pierre
>
> . . .
>
> What prompted this discussion is that due to
> performance (and other) concerns, a lot of
> people are running caching responders today,
> and want their responses to be accepted by
> clients of type 2.


[mm] To my count, "a lot" is two among the
     twelve server-side implementors who
     responded to the prior poll.

>
> [well-reasoned v2-relevant discussion . . . ]
>

[mm] I agree there exists many variations
     in a v2 context and I agree that this
     WG should consider all such in the
     timeframe of that potential standard.

[mm] Meanwhile, what should we do for v1?
     The current de-facto default is that
     a nonce may be ignored. Does this WG
     support that premise?

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H1a0I7023814 for <[e-mail]>; Thu, 16 Oct 2003 18:36:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9H1Zxui023813 for ietf-pkix-bks; Thu, 16 Oct 2003 18:35:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imr7.us.db.com (imr7.us.db.com [160.83.77.105]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H1ZwI7023808 for <[e-mail]>; Thu, 16 Oct 2003 18:35:59 -0700 (PDT) (envelope-from [e-mail])
Received: from sdbo1005.db.com by imr7.us.db.com  id h9H1ZvFa025814; Thu, 16 Oct 2003 21:35:57 -0400
Subject: Re: POLL: Nonce-specific error code for OCSP
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Thu, 16 Oct 2003 21:35:56 -0400
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.12  |February 13, 2003) at 10/16/2003 09:35:57 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

NO

Frank



                                                                                                                                       
                      "Michael Myers"                                                                                                  
                      <[e-mail]        To:       <[e-mail]>                                                           
                      >                        cc:                                                                                     
                      Sent by:                 Subject:  POLL: Nonce-specific error code for OCSP                                      
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      10/15/2003 05:02                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       





All,

I recently received permission from the chairs to poll the WG
against the following question.

Should we standardize an OCSP *V1* error code that enables a
responder to indicate its inability to respond to nonced
requests?

Please respond with either YES or NO.

Mike







--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H0IpI7021117 for <[e-mail]>; Thu, 16 Oct 2003 17:18:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9H0IpIx021116 for ietf-pkix-bks; Thu, 16 Oct 2003 17:18:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H0IoI7021110 for <[e-mail]>; Thu, 16 Oct 2003 17:18:50 -0700 (PDT) (envelope-from [e-mail])
Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id h9H0Ilq10893 for <[e-mail]>; Thu, 16 Oct 2003 17:18:47 -0700 (PDT)
Received: from kitty.nscp.aoltw.net ([10.169.25.23]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HMVKV900.72M; Thu, 16 Oct 2003 17:18:45 -0700 
Date: Thu, 16 Oct 2003 17:20:34 -0700
From: [e-mail] (Julien Pierre)
Subject: Re: POLL: Nonce-specific error code for OCSP
To: [e-mail]
cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: AOL Communicator (20031015Trnk.3 Win)
Organization: Netscape
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080802040505"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

NO.

-- 
I am the dog in dogfood

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKIjCC
AoQwggFsoAMCAQICAgORMA0GCSqGSIb3DQEBBQUAMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UE
CxMIVEVDSCBERVYxEDAOBgNVBAMTB0FPTCBLRVkwHhcNMDMxMDE2MDI0NzMzWhcNMDQwNDEz
MDI0NzMzWjAWMRQwEgYDVQQDEwtqcGllcnJlMDI2NDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAvOtZTw6Jx0k4YN4jvCraClKIRXv6u0lI43XeVqTj30wHrZ7mcYq8+MSvoiKyCk4y
9tK81T2c6ECWWvzn9CuzHztax0EWBctoqnf4V7kzhZfeKUi7zJ6UUa/DkzFYOHWLzybIRcdV
2v9Lvmb4cQPOSOhFO61ccfE9vs4zm+2VrdcCAwEAAaNDMEEwDgYDVR0PAQH/BAQDAgXgMC8G
A1UdEQQoMCaBD2pwaWVycmVAYW9sLm5ldIETanBpZXJyZTAyNjRAYW9sLmNvbTANBgkqhkiG
9w0BAQUFAAOCAQEATiGEDdIha9TCGhP75eTa0cTiI+1Hehs0wvYbiYNf5tu/PD8uae8SUXFn
6USDucxhCEaCtJK5GEYYYk7fBuatSib61/K6Sq413adHwk8HICtWuyU0PTKxZk1A740GfxnK
HY1dZlJVIgcBxAUXG+mxgtLgvFizPHb6pBmGa/BGGDHfbuCOFmetX8kc5JFLxL8vss+PiZWA
JIhwp6UREvU3NQwaFLq69/zGfzEMGcugavG4124ZWdMSebezXeRWNaRFM2afD9KjGBC4FV5f
BqotN6idCnpqKnDwhGuI/N/N91F5MMacDD/PdNjt/DuBR78xl5fd+nBwjIAgJKRMXk4OmDCC
A5kwggKBoAMCAQICAQcwDQYJKoZIhvcNAQEFBQAwMzEMMAoGA1UEChMDQU9MMREwDwYDVQQL
EwhURUNIIERFVjEQMA4GA1UEAxMHVEVTVCBDQTAeFw0wMzA2MjYwMDM5NTFaFw0wODA2MjQy
MzM5NTFaMDMxDDAKBgNVBAoTA0FPTDERMA8GA1UECxMIVEVDSCBERVYxEDAOBgNVBAMTB0FP
TCBLRVkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPuXAqR0wNCMoPF1qnFDix
K2db1P9v1f/9i1nyejlYCuwAykidFIo+gaNKU6OHjnQAW0eDzwdfa/yq+AqZI8P2weMWdxA1
KeGCvEvYuYk9PmjEjLx5vXPVCSSTb4vOeoBsWXlZElNF9bWReJ+mgp5TmujRS6PaG7PkVWsk
T9OAozvVKRMY7SMvqIznOK6nm9A9d9hyFFMy9X3wL46k56782kXDAx6XzsGnxN6aJpo7aISd
e7fuvDj60EkEnVe3D7XOuqqWN1riTXiH4NlapFnNrpBlrqPx4Zz6ckCp0yA9NfsP0IqLp0tI
WsU5t+zODIQtmAwXIiyMJ1LOHXibSQRpAgMBAAGjgbcwgbQwHwYDVR0jBBgwFoAU8hIIcf+A
y6tpx1QG2H1tOkOIj8gwHQYDVR0OBBYEFNTbBXTfuPOxMnsfcMZ3mLYUE5dnMA8GA1UdEwEB
/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMBEGCWCGSAGG+EIBAQQEAwIDuDA+BggrBgEFBQcB
AQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly90ZGNhLm5zY3AuYW9sdHcubmV0OjgxL29jc3Aw
DQYJKoZIhvcNAQEFBQADggEBAGYJn/C6nQ827CKmOGsMJCpAqnkc7/lAkMPMtuAIWdNIg1es
5//U4pmn9okHrm2wenT5lFk5X0SihHiaIGChY/RkgGVzPGiVBJpBcxDJiqT2HOWOsPIU6uhq
dHZctRbZl10qz4Y1lPlfymBfXJ4zNbeoV8z+G2zNFPwzRZS1OYifWjwXc8b4qLwRdMRYaWaa
QALnXf9bopjnjK9Qo+55Vmfr1QZaAx9wktMi5f3dSu5eeUK1f+5M3Yuc/SylbpiFD5daLhpL
fQIkBhG3juuARY/7fblxpo6eldml2g41cKowxlU2GMg4OCRiPvCvHAetPKQ0Fv4MRor1hsQS
OC8GsuIwggP5MIIDYqADAgECAgJwuTANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCVVMx
CzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNh
IE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJh
bmV0IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMzA4MjYyMDIxMjJaFw0wNDAyMjIyMDIx
MjJaMHsxCzAJBgNVBAYTAlVTMRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxFzAVBgoJ
kiaJk/IsZAEBEwdqcGllcnJlMR4wHAYJKoZIhvcNAQkBFg9qcGllcnJlQGFvbC5uZXQxFjAU
BgNVBAMTDUp1bGllbiBQaWVycmUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOWhFGwP
NuTnPV2LjYcyYghp5ZR1wjC7LDUbets5CsANFCGY2FHJ/eZBzOzO8/gWrCrX4xdcwA9nji9k
lajS28uGWxA7Hyco3VmdMOmUwUfJqxcudm0gf991Ut+qQC6pFXLXmuVJuVy8kNOrMxr2Ml7U
I5/1JbmB2839L+W9pibpAgMBAAGjggFxMIIBbTAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0lBBYw
FAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQgYnkgTmV0c2Nh
cGUgQ2VydGlmaWNhdGUgTWFuYWdlbWVudCBTeXN0ZW0gNC41MIGSBgNVHREEgYowgYeBD2pw
aWVycmVAYW9sLm5ldIEWanVsaWVuX3BpZXJyZUBtY29tLmNvbYEQanBpZXJyZUBtY29tLmNv
bYEaanVsaWVuX3BpZXJyZUBuZXRzY2FwZS5jb22BFGpwaWVycmUwMjY0QG1jb20uY29tgRhq
cGllcnJlMDI2NEBuZXRzY2FwZS5jb20wHwYDVR0jBBgwFoAUKduyLYN+f4sju8LMZrk56Cnz
AoYwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRwOi8vY2VydGlmaWNhdGVzLm5l
dHNjYXBlLmNvbS9vY3NwMA0GCSqGSIb3DQEBBQUAA4GBANnuPQppIwMT5atjpnKRyPr7o2wN
cXgkmRwQ+IsGqxjObF0xiU5/r2aBVnOFClxsfo9bKGXYPpz8YiKiQPDC3gz903RznGmBjzHZ
VmXW6syq3tnkFm4l7Ya55AOSsJ7psNdmOcnMQp8P4ZphLanh3wcgYO7DRq1YavxEVAnHxBcB
MYIC8jCCAu4CAQEwOTAzMQwwCgYDVQQKEwNBT0wxETAPBgNVBAsTCFRFQ0ggREVWMRAwDgYD
VQQDEwdBT0wgS0VZAgIDkTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzEwMTcwMDIwMzVaMCMGCSqGSIb3DQEJBDEWBBRYkkgG
qOiudkPq93RrzKkqZhx2EjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBqwYJKwYB
BAGCNxAEMYGdMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1v
dW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9M
IFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
AgJwuTCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJD
QTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5j
MRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZp
Y2F0ZSBBdXRob3JpdHkCAnC5MA0GCSqGSIb3DQEBAQUABIGAf+5gLhSVNhtjyGMEwJCVoLIq
F8O33DY2MPTN41XL0cwd93z5lXRi/pRZGhL3ykm1+gRllmYRyOEGpOiTvo4heQYc9GVLJAhi
R2DAhHkFRKwGA85P+2ZbX/6KMOmCIbPu7yMHJ3M2LsxhS5Jz04xb9UuCjy1y85T7A2XJcLiE
hhoAAAAAAAA=

--------------ms010704000904080802040505--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H0EbI7020884 for <[e-mail]>; Thu, 16 Oct 2003 17:14:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9H0Eb4p020883 for ietf-pkix-bks; Thu, 16 Oct 2003 17:14:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from scale01.mcom.com (h-64-236-139-249.aoltw.net [64.236.139.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9H0EVI7020873 for <[e-mail]>; Thu, 16 Oct 2003 17:14:32 -0700 (PDT) (envelope-from [e-mail])
Received: from aol.net ([10.169.25.23]) by scale01.nscp.aoltw.net (Netscape Messaging Server 6.1 (built Oct  3 2002)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 16 Oct 2003 17:14:17 -0700 (PDT)
Date: Thu, 16 Oct 2003 17:16:19 -0700
From: Julien Pierre <[e-mail]>
Subject: Re: POLL: Nonce-specific error code for OCSP
In-reply-to: <[e-mail]>
To: [e-mail]
Reply-to: [e-mail]
Message-id: <[e-mail]>
Organization: America On-Line, Inc
MIME-version: 1.0
Content-type: multipart/signed; boundary=------------ms060809060100060006010102; micalg=sha1; protocol="application/x-pkcs7-signature"
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms060809060100060006010102
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Michael Myers wrote:

>Julien,
>
>I modified the subject line to keep the POLL thread clean for
>votes.
>
>OCSP errors are unsigned to enable handling of DOS-type attacks
>at the edge rather than the core.  This feature was argued in
>favor of those who might deploy this protocol using pre-produced
>responses.
>
The nonce extension was introduced so that clients could make sure that 
they would get fresh responses from a live OCSP responder.
If we add an unsigned error code in the clear to state that the OCSP 
responder is not live and therefore can't sign nonce requests, then the 
purpose of the nonce extension can be easily defeated by a attacker who 
can replay that error code and fool the client into thinking that he is 
not talking to a live responder. I believe that is a security hole that 
defeats the purpose of nonce. This case is much different from DOS 
cases. Due to the other unsigned error codes in OCSP, DOS attacks cannot 
be avoided. But a client can handle them properly, by considering them 
the same as a failure to validate.
On the other hand with this "caching responder" error code, some invalid 
certs that were recently revoked might be considered valid because an 
attacker sent this error code, then served an older good cached response 
for the recently revoked cert. Validating invalid certs is a much more 
serious problem than DOS, in my opinion.

In the end, there are really only two real-world cases, and they come 
down to the OCSP client's policy :
1) If the client is willing to accept pre-produced responses, it should 
not send nonce in the OCSP request. End of story, all signed responses 
are good. The client is subject to replay attacks, but it is aware of 
that fact - that's how it was configured.
2) If the client insists on talking to a live responder, it should send 
nonce in the OCSP request, and check for the same nonce in the OCSP 
response. If they match, the response is accepted, otherwise, they are 
not accepted.

What prompted this discussion is that due to performance (and other) 
concerns, a lot of people are running caching responders today, and want 
their responses to be accepted by clients of type 2.
I don't think that's a good thing because nonce was specifically 
introduced to prevent replay attacks, and as a result, is incompatible 
with caching responders. The clients that send nonce in their requests 
are very few, but they probably have good reasons to do so.

>  That said, presenting a pre-fetched (pre-signed?)
>error response does nothing to mitigate anti-replay.
>
Not true if that response has an expiration time. As I mentioned above, 
to be useful, this signed error response would need to have a validity 
period : ie. between times t1 and t2, this responder may send 
pre-produced responses. If this cached signed response was sent, the 
client could be reasonably sure that the server truly intended to send 
cached responses for that period. This does mean that periodically (when 
t2 comes up), the caching responders would have to refetch this error 
response from the master (live) responder. However it still allows 
caching to work by dramatically reducing the signature operations.
This new type of error response would enable a third type of OCSP client 
policy that is not possible today :

3) Clients that prefer signed OCSP responses, but are willing to accept 
cached responses if the server can convince them that it is a caching 
responder.
They would work by sending a request with nonce. They would only fall 
back to accepting no-nonce responses if they first received a signed 
response with the "caching responder" error code from the responder. And 
they would only accept the pre-produced responses if the time of their 
OCSP requests fell between t1 and t2.

There could also be a statement in the "caching responder" response as 
to the maximum age of the subsequent cached responses. This would 
partially protect against replay attacks from the beginning of time.

I think this is definitely not something to consider for OCSP v1, but it 
can be discussed for v2.


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK7zCC
A1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoXDTA0MDYyOTIxMjQwMFowgYIx
DzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYwFAYDVQQDEw1KdWxpZW4gUGll
cnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBlLmNvbTEhMB8GCSqGSIb3DQEJ
ARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
yifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWog7k4ZlmDoFRIpZHOlmxC3K9q
Jda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz9GXihPQLtv5z/slSEGYNPafh
HaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgGNiO4jWUSN3HNqk9ZGTyC+Adp
Tzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHKCoF/h5PSOHptCKMzZ0IOz9gB
F3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1oIX2lQIDAQABo0UwQzAzBgNV
HREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJhaW5AcmF3YncuY29tMAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLrNzrtCm/4tuRXXxxf6HQW4pxu
0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRticjuYEQOAPCz0VAR25nkV87ONK
D8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZXUwhNRDJh5MaSoUwggOSMIIC
+6ADAgECAgQEAAMRMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9H
VEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDMwODA3
MTQwNjAwWhcNMDQwODA3MjM1OTAwWjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYw
FAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAX
BgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRl
IEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpv
iy+BTWf/vUoPYy7E3IX2nixJJiD/ABfkiIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG
0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQpbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S
2rISS40CAwEAAaOCAT4wggE6MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGlj
LXRydXN0LmNvbS9jZ2ktYmluL0NSTC8yMDA2L2NkcC5jcmwwHQYDVR0OBBYEFCnbsi2Dfn+L
I7vCzGa5Oegp8wKGMFQGA1UdIARNMEswSQYKKoZIhvhjAQIBBTA7MDkGCCsGAQUFBwIBFi1o
dHRwOi8vd3d3LnB1YmxpYy10cnVzdC5jb20vQ1BTL09tbmlSb290Lmh0bWwwWAYDVR0jBFEw
T6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UE
AxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI
MAYBAf8CAQEwDQYJKoZIhvcNAQEFBQADgYEAQyL9bXdvIuqlX+GUiI5s0kxfCeUovkr7qTuc
rXa0vizFB6/md/zNy0uCTtQnTX99HdJp4GWjFlsUc510rsfyDt6goK5C12l90nKSILxfRfRJ
FfWUz7n6KhsXM9TdkVjd6TpCdSZunuSQC0YeVQPQ81t5joJvuEK3BJrvIjYWyj4wggP6MIID
Y6ADAgECAgJwujANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB
MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMx
GTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmlj
YXRlIEF1dGhvcml0eTAeFw0wMzA4MjYyMDIxMjJaFw0wNDAyMjIyMDIxMjJaMHsxCzAJBgNV
BAYTAlVTMRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxFzAVBgoJkiaJk/IsZAEBEwdq
cGllcnJlMR4wHAYJKoZIhvcNAQkBFg9qcGllcnJlQGFvbC5uZXQxFjAUBgNVBAMTDUp1bGll
biBQaWVycmUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANgwx0yMW+8PDIrR6gBCA+eL
3K6RKwiuQSAaYc33/kS/Jf0vsmVbl+ozQfwChPlBA4+fAA/LoKNMnP1RXcYihwY2FZvWjAKJ
GWFBBkND2m6BLDbxvfXosJd9IsO/VqloSAbfEbLq6SFFi/UK/HezzOCDwfb5viHJPbJI/Stk
HVHhAgMBAAGjggFyMIIBbjAPBgNVHQ8BAf8EBQMDB4AAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDBDBglghkgBhvhCAQ0ENhY0SXNzdWVkIGJ5IE5ldHNjYXBlIENlcnRpZmlj
YXRlIE1hbmFnZW1lbnQgU3lzdGVtIDQuNTCBkgYDVR0RBIGKMIGHgQ9qcGllcnJlQGFvbC5u
ZXSBFmp1bGllbl9waWVycmVAbWNvbS5jb22BEGpwaWVycmVAbWNvbS5jb22BGmp1bGllbl9w
aWVycmVAbmV0c2NhcGUuY29tgRRqcGllcnJlMDI2NEBtY29tLmNvbYEYanBpZXJyZTAyNjRA
bmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUF
BwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20v
b2NzcDANBgkqhkiG9w0BAQUFAAOBgQBLVKWb0Z7oB/sCYOEJXHixg3913rpO9KulCIJSFxxT
3KRUUuicC6NL1r70RnGmw4FINOIzNtsvADuha/WXARlEP8tmrMLCnaFGRPkcHq3P/7fa8hIa
XzxTlJzqIqvW9UkURT/ROEscB+9bnWqXp6g31KNbrl6iY6FWkTH1/9vxBzGCA1QwggNQAgEB
MIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZp
ZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xv
Z2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJwujAJBgUr
DgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
MzEwMTcwMDE2MTlaMCMGCSqGSIb3DQEJBDEWBBSshVvqjclS+MzjX5lEaVqb6MAlLzBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBqwYJKwYBBAGCNxAEMYGdMIGaMIGSMQswCQYD
VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzAN
BgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMT
H1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwpBMjCBrQYLKoZIhvcNAQkQAgsx
gZ2ggZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2
aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCkEyMA0G
CSqGSIb3DQEBAQUABIGA0uLcb0OKx9oWzUlhv0eLhvt8cxIYlAa5/lYEgco97gOFSEt/wkry
i5b3UqdTj5+m/FMaFNL117J6OMjSCT7OpXYoUJGMytS7CSNhPn1jopkvTFH3OBpWLuTglwAl
pBLjOk4ZYd5b3iVJCe+Vu0TZA9gL5pniwRwuSnCuNt0E4Y0AAAAAAAA=
--------------ms060809060100060006010102--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GNakI7019273 for <[e-mail]>; Thu, 16 Oct 2003 16:36:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GNakLn019272 for ietf-pkix-bks; Thu, 16 Oct 2003 16:36:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GNajI7019267 for <[e-mail]>; Thu, 16 Oct 2003 16:36:45 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h9GNajt85060; Thu, 16 Oct 2003 16:36:45 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Thu, 16 Oct 2003 16:39:49 -0700
Message-ID: <[e-mail]>
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)
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

I modified the subject line to keep the POLL thread clean for
votes.

OCSP errors are unsigned to enable handling of DOS-type attacks
at the edge rather than the core.  This feature was argued in
favor of those who might deploy this protocol using pre-produced
responses.  That said, presenting a pre-fetched (pre-signed?)
error response does nothing to mitigate anti-replay.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Julien Pierre
> Sent: Thursday, October 16, 2003 2:28 PM
> To: [e-mail]
> Subject: Re: POLL: Nonce-specific error code for OCSP
>
>
> Florian Oelmaier wrote:
>
> >Rationale:
> >My first idea was to say: if it is OPTIONAL for the
> responder to use that error code it is ok. But in
> fact even the OPTIONAL inclusion harms the security
> of the protocol, as an attacker can fool clients into
> believing a particular OCSP-Responder would not
> support nonces, when in fact it does.
> >
> Agreed. The OCSP responses with error codes are not
> signed, so this
> would present a security hole. We should not let the
> server return this
> error code in an unsigned response.
>
> IMO, it would be acceptable to have an error code
> only if the response
> was signed and included a validity period. Each
> caching responder would
> have to prefetch such a response in order to be able
> to serve it back to
> clients that send nonces.
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GNS2I7019020 for <[e-mail]>; Thu, 16 Oct 2003 16:28:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GNS2tG019019 for ietf-pkix-bks; Thu, 16 Oct 2003 16:28:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.ntcif.telstra.com.au ([202.12.233.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GNS0I7019008 for <[e-mail]>; Thu, 16 Oct 2003 16:28:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from uucp@localhost) by mailbo.ntcif.telstra.com.au (8.8.2/8.6.9) id JAA17520 for <[e-mail]>; Fri, 17 Oct 2003 09:27:53 +1000 (EST)
Received: from mailbi.ntcif.telstra.com.au(202.12.162.19) via SMTP by mailbo.ntcif.telstra.com.au, id smtpdvZaOLY; Fri Oct 17 09:11:08 2003
Received: (from uucp@localhost) by mailbi.ntcif.telstra.com.au (8.8.2/8.6.9) id JAA07014 for <[e-mail]>; Fri, 17 Oct 2003 09:11:04 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdalaOcn; Fri Oct 17 09:10:37 2003
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA18772 for <[e-mail]>; Fri, 17 Oct 2003 09:10:36 +1000 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Fri, 17 Oct 2003 09:10:13 +1000
Message-ID: <[e-mail]>
Thread-Topic: POLL: Nonce-specific error code for OCSP
Thread-Index: AcOTeSAPI4+xTpd0QSCIm0NHvcO4JQAwTS2w
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9GNS1I7019015
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

NO

----------
From: Michael Myers [mailto:[e-mail]]
Sent: Thursday, 16 October 2003 7:03 AM

Should we standardize an OCSP *V1* error code that enables a responder to indicate its inability to respond to nonced requests?

Please respond with either YES or NO.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GLZQI7011562 for <[e-mail]>; Thu, 16 Oct 2003 14:35:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GLZQXJ011561 for ietf-pkix-bks; Thu, 16 Oct 2003 14:35:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GLZPI7011554 for <[e-mail]>; Thu, 16 Oct 2003 14:35:25 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AAFjN-0002ah-P5; Thu, 16 Oct 2003 17:32:25 -0400
X-test-idtracker: no
To: IETF-Announce :;
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Last Call: 'X.509 Extensions for IP Addresses and AS Identifiers' to  Proposed Standard 
Reply-to: [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 16 Oct 2003 17:32:25 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the Public-Key Infrastructure (X.509) WG to 
consider the following document:

- 'X.509 Extensions for IP Addresses and AS Identifiers'
   <draft-ietf-pkix-x509-ipaddr-as-extn-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2003-10-30.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-03.txt



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GLQ6I7010870 for <[e-mail]>; Thu, 16 Oct 2003 14:26:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GLQ6ol010869 for ietf-pkix-bks; Thu, 16 Oct 2003 14:26:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from scale01.mcom.com (h-64-236-139-249.aoltw.net [64.236.139.249]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GLQ5I7010859 for <[e-mail]>; Thu, 16 Oct 2003 14:26:06 -0700 (PDT) (envelope-from [e-mail])
Received: from aol.net ([10.169.25.23]) by scale01.nscp.aoltw.net (Netscape Messaging Server 6.1 (built Oct  3 2002)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 16 Oct 2003 14:25:47 -0700 (PDT)
Date: Thu, 16 Oct 2003 14:27:49 -0700
From: Julien Pierre <[e-mail]>
Subject: Re: POLL: Nonce-specific error code for OCSP
In-reply-to: <[e-mail]>
To: [e-mail]
Reply-to: [e-mail]
Message-id: <[e-mail]>
Organization: America On-Line, Inc
MIME-version: 1.0
Content-type: multipart/signed; boundary=------------ms010503050308040105020007; micalg=sha1; protocol="application/x-pkcs7-signature"
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms010503050308040105020007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Florian Oelmaier wrote:

>Rationale: 
>My first idea was to say: if it is OPTIONAL for the responder to use that error code it is ok. But in fact even the OPTIONAL inclusion harms the security of the protocol, as an attacker can fool clients into believing a particular OCSP-Responder would not support nonces, when in fact it does.
>
Agreed. The OCSP responses with error codes are not signed, so this 
would present a security hole. We should not let the server return this 
error code in an unsigned response.

IMO, it would be acceptable to have an error code only if the response 
was signed and included a validity period. Each caching responder would 
have to prefetch such a response in order to be able to serve it back to 
clients that send nonces.


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK7zCC
A1cwggLAoAMCAQICAwpBMjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDYzMDIxMjQwMFoXDTA0MDYyOTIxMjQwMFowgYIx
DzANBgNVBAQTBlBpZXJyZTEPMA0GA1UEKhMGSnVsaWVuMRYwFAYDVQQDEw1KdWxpZW4gUGll
cnJlMSMwIQYJKoZIhvcNAQkBFhRqcGllcnJlQG5ldHNjYXBlLmNvbTEhMB8GCSqGSIb3DQEJ
ARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
yifKcMKlTYGJ06ltDGQUcwqnWv0I+GegpPVluxR2MvRTunWog7k4ZlmDoFRIpZHOlmxC3K9q
Jda876lUkonNNdDgS87qGyWIxylrzLNFfiZBKzcx2ivSiLkz9GXihPQLtv5z/slSEGYNPafh
HaWcm01oLrywNbhY4zb9qAgru3vw+4ZFRCqNE1wgZoZAGxgGNiO4jWUSN3HNqk9ZGTyC+Adp
Tzmms8TXMA69PUZgyK6WwMwzsWHPnx008hmVpAzHyYcX0ZHKCoF/h5PSOHptCKMzZ0IOz9gB
F3ngNZxXEoEsle0Ynnu7I5/CcYO3NmBoH7fWsFwfl1cbl8v1oIX2lQIDAQABo0UwQzAzBgNV
HREELDAqgRRqcGllcnJlQG5ldHNjYXBlLmNvbYESbWFkYnJhaW5AcmF3YncuY29tMAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAuTVM8HQ/hcLrNzrtCm/4tuRXXxxf6HQW4pxu
0Pojr49aloK7MX3ZVTHGpnRlMuxKNyHgjh7aAFM66GgaRticjuYEQOAPCz0VAR25nkV87ONK
D8CVo///cL7Xy5T8B9d0NQVo0zdK4GjPRabIi3woNF1fbvzZXUwhNRDJh5MaSoUwggOSMIIC
+6ADAgECAgQEAAMRMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9H
VEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3QwHhcNMDMwODA3
MTQwNjAwWhcNMDQwODA3MjM1OTAwWjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYw
FAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAX
BgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRl
IEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4u9fLHZDiUsaX7Pl+Kpv
iy+BTWf/vUoPYy7E3IX2nixJJiD/ABfkiIhp3v2DV+CjERkRqtbcvO+z0hUuVMZufL/ZucNG
0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQpbzBpNF4TAblZEH8BSVjJuvvDMduVKGMzlRXth+S
2rISS40CAwEAAaOCAT4wggE6MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGlj
LXRydXN0LmNvbS9jZ2ktYmluL0NSTC8yMDA2L2NkcC5jcmwwHQYDVR0OBBYEFCnbsi2Dfn+L
I7vCzGa5Oegp8wKGMFQGA1UdIARNMEswSQYKKoZIhvhjAQIBBTA7MDkGCCsGAQUFBwIBFi1o
dHRwOi8vd3d3LnB1YmxpYy10cnVzdC5jb20vQ1BTL09tbmlSb290Lmh0bWwwWAYDVR0jBFEw
T6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UE
AxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI
MAYBAf8CAQEwDQYJKoZIhvcNAQEFBQADgYEAQyL9bXdvIuqlX+GUiI5s0kxfCeUovkr7qTuc
rXa0vizFB6/md/zNy0uCTtQnTX99HdJp4GWjFlsUc510rsfyDt6goK5C12l90nKSILxfRfRJ
FfWUz7n6KhsXM9TdkVjd6TpCdSZunuSQC0YeVQPQ81t5joJvuEK3BJrvIjYWyj4wggP6MIID
Y6ADAgECAgJwujANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB
MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMx
GTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmlj
YXRlIEF1dGhvcml0eTAeFw0wMzA4MjYyMDIxMjJaFw0wNDAyMjIyMDIxMjJaMHsxCzAJBgNV
BAYTAlVTMRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxFzAVBgoJkiaJk/IsZAEBEwdq
cGllcnJlMR4wHAYJKoZIhvcNAQkBFg9qcGllcnJlQGFvbC5uZXQxFjAUBgNVBAMTDUp1bGll
biBQaWVycmUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANgwx0yMW+8PDIrR6gBCA+eL
3K6RKwiuQSAaYc33/kS/Jf0vsmVbl+ozQfwChPlBA4+fAA/LoKNMnP1RXcYihwY2FZvWjAKJ
GWFBBkND2m6BLDbxvfXosJd9IsO/VqloSAbfEbLq6SFFi/UK/HezzOCDwfb5viHJPbJI/Stk
HVHhAgMBAAGjggFyMIIBbjAPBgNVHQ8BAf8EBQMDB4AAMB0GA1UdJQQWMBQGCCsGAQUFBwMC
BggrBgEFBQcDBDBDBglghkgBhvhCAQ0ENhY0SXNzdWVkIGJ5IE5ldHNjYXBlIENlcnRpZmlj
YXRlIE1hbmFnZW1lbnQgU3lzdGVtIDQuNTCBkgYDVR0RBIGKMIGHgQ9qcGllcnJlQGFvbC5u
ZXSBFmp1bGllbl9waWVycmVAbWNvbS5jb22BEGpwaWVycmVAbWNvbS5jb22BGmp1bGllbl9w
aWVycmVAbmV0c2NhcGUuY29tgRRqcGllcnJlMDI2NEBtY29tLmNvbYEYanBpZXJyZTAyNjRA
bmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUF
BwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20v
b2NzcDANBgkqhkiG9w0BAQUFAAOBgQBLVKWb0Z7oB/sCYOEJXHixg3913rpO9KulCIJSFxxT
3KRUUuicC6NL1r70RnGmw4FINOIzNtsvADuha/WXARlEP8tmrMLCnaFGRPkcHq3P/7fa8hIa
XzxTlJzqIqvW9UkURT/ROEscB+9bnWqXp6g31KNbrl6iY6FWkTH1/9vxBzGCA1QwggNQAgEB
MIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZp
ZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xv
Z2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJwujAJBgUr
DgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
MzEwMTYyMTI3NDlaMCMGCSqGSIb3DQEJBDEWBBQzuEKS2OpFZ6bfgJU65wteqNILazBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBqwYJKwYBBAGCNxAEMYGdMIGaMIGSMQswCQYD
VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzAN
BgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMT
H1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwpBMjCBrQYLKoZIhvcNAQkQAgsx
gZ2ggZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2
aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCkEyMA0G
CSqGSIb3DQEBAQUABIGAD7+S+pfCqKRsVFAj1BkXSCpogscIUyVbL2GaMn8dfso4xsaqoUQ4
5xpvPSuK4AWuDR0r5+K+4fVY3o3Ox/x153s5EdS/SlpLb53Qqy7QDjRNkTd2ifuqQ6J7sgPg
VWfaSvKHyF0soB3ELaSlln6US6TieGoHxWnxE9M40hWLVrsAAAAAAAA=
--------------ms010503050308040105020007--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GKfqI7007804 for <[e-mail]>; Thu, 16 Oct 2003 13:41:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GKfqaq007803 for ietf-pkix-bks; Thu, 16 Oct 2003 13:41:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-m02.mx.aol.com (imo-m02.mx.aol.com [64.12.136.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GKfoI7007797 for <[e-mail]>; Thu, 16 Oct 2003 13:41:50 -0700 (PDT) (envelope-from [e-mail])
Received: from [e-mail] by imo-m02.mx.aol.com (mail_out_v36_r1.1.) id 7.142.1ac23445 (16111) for <[e-mail]>; Thu, 16 Oct 2003 16:38:47 -0400 (EDT)
Received: from  pc655301.nscp.aoltw.net (h-10-169-25-82.nscp.aoltw.net [10.169.25.82]) by air-id12.mx.aol.com (v96.8) with ESMTP id MAILINID123-3eef3f8f01d529e; Thu, 16 Oct 2003 16:38:46 -0400
Date: Thu, 16 Oct 2003 13:38:40 -0700
From: "Terry Hayes" <[e-mail]>
Subject: Re: POLL: Nonce-specific error code for OCSP
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: AOL Communicator (20031013Trnk.1 Win)
Organization: AOL
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.25.82
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

NO 

The response should be as if the nonce extension was not present in the request. An 
implementation that does not support nonces should simply ignore the extension and 
generate (provide) a non-nonced response. 

The error code does not serve any purpose. Since, the error response is not signed, the 
client cannot use it to implement a policy that allows using a non-nonced response 
in cases where the server does not support nonces.  I believe this is one proposed use 
of this error code. 

Terry 


Michael Myers wrote on 10/15/2003, 2:02 PM: 

All, 

I recently received permission from the chairs to poll the WG 
against the following question. 

Should we standardize an OCSP *V1* error code that enables a 
responder to indicate its inability to respond to nonced 
requests? 

Please respond with either YES or NO. 

Mike 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHckI7097411 for <[e-mail]>; Thu, 16 Oct 2003 10:38:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GHckVB097410 for ietf-pkix-bks; Thu, 16 Oct 2003 10:38:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from infoblox.com (trevise.infoblox.com [209.209.39.217]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GHciI7097405 for <[e-mail]>; Thu, 16 Oct 2003 10:38:44 -0700 (PDT) (envelope-from [e-mail])
Received: from infoblox.com (205.158.171.194.ptr.us.xo.net [205.158.171.194]) by infoblox.com (Postfix) with ESMTP id 0633754437; Thu, 16 Oct 2003 10:38:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 16 Oct 2003 10:36:59 -0700
From: Richard Sinn <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>, [e-mail]
Subject: Re: POLL: Nonce-specific error code for OCSP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

YES.

In general, the less information given out, the more secure the 
environment is. However, if I view OCSP could run in two different 
modes, one with nonce and one without, then, an error code will be 
useful to indicate which type of responder is out there. However, I 
agree with Denis, a resume of advantages vs disadvantages would be 
useful ... just do not want to miss anything.

Thanks,

Richard Sinn
Infoblox, Inc.


Michael Myers wrote:

>All,
>
>I recently received permission from the chairs to poll the WG
>against the following question.
>
>Should we standardize an OCSP *V1* error code that enables a
>responder to indicate its inability to respond to nonced
>requests?
>
>Please respond with either YES or NO.
>
>Mike
>
>
>
>  
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GG25I7094113 for <[e-mail]>; Thu, 16 Oct 2003 09:02:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GG25qn094112 for ietf-pkix-bks; Thu, 16 Oct 2003 09:02:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GG24I7094106 for <[e-mail]>; Thu, 16 Oct 2003 09:02:04 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h9GG25t58730 for <[e-mail]>; Thu, 16 Oct 2003 09:02:05 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Thu, 16 Oct 2003 09:05:09 -0700
Message-ID: <[e-mail]>
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Thursday, October 16, 2003 12:34 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: POLL: Nonce-specific error code for OCSP
>
>
>
> Mike,
>
> > All,
>
> > I recently received permission from the chairs to
> poll the WG
> > against the following question.
>
> > Should we standardize an OCSP *V1* error code that enables a
> > responder to indicate its inability to respond to nonced
> > requests?
>
> > Please respond with either YES or NO.
>
> I would suggest to you provide a resumé of the
> advantages of this new error
> code (and disadvantages if not supported), so that
> people do not have to
> look back at that long thread on that topic to make
> up their opinion.
>
> Denis
>
> > Mike



A reasonable request.

In summary, we need to standardize the treatment of nonces when
nonces aren't supported.  RFC2560 is regrettably silent on the
point.  The need to do so is particularly acute in the context
of heterogeneous populations of clients and servers (i.e. not
operating under a single administrative authority).  Some may be
set up to use or support nonces and some may not.  The question
is of course moot for requests that don't contain nonces.

The issue is further complicated by the use of pre-produced
responses to achieve scalability through caching (i.e.
non-signing) servers.  A relay back to a master signing server
could work, but that doesn't seem to be a popular option.  So
that leaves us with two server-side options.  Either: 1) send
back a non-nonced response anyway with technical extensions; or
2) send back an error code.

Variations on option 1 have been discussed, with the likelihood
that an extended response syntax or equivalent technical
mechanisms will force a v2 and all that entails with regard to
IETF process.

Yet we also need to do something sooner about v1.  In this case,
an existing error could be designated or we could define a new
one that servers can send back in the event they don't support
nonces.  Absent a designated error code, it is predictable that
ad-hoc selections will be made to to address the issue with a
consequent reduction in Internet-wide OCSP interoperability and
security.

This poll is focussed on the narrower v1 issue ONLY. Should we
or should we not standardize a v1 error code? If this poll is
inconclusive, then I suppose we'll get into the heart of the
matter, which is whether it is acceptable in v1 to disregard a
client's nonce.  But let's leave those discussions to another
thread and first get a vote tally.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GERRI7089219 for <[e-mail]>; Thu, 16 Oct 2003 07:27:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9GERRax089218 for ietf-pkix-bks; Thu, 16 Oct 2003 07:27:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zinc.btinternet.com (zinc.btinternet.com [194.73.73.148]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9GERPI7089211 for <[e-mail]>; Thu, 16 Oct 2003 07:27:26 -0700 (PDT) (envelope-from [e-mail])
Received: from dial81-135-45-31.in-addr.btopenworld.com ([81.135.45.31] helo=LiaquatDELL) by zinc.btinternet.com with esmtp (Exim 3.22 #23) id 1AA95s-00027P-00; Thu, 16 Oct 2003 15:27:13 +0100
Reply-To: <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, <[e-mail]>
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Thu, 16 Oct 2003 15:26:37 +0100
Message-ID: <006a01c393f1$95d8ca40$5ed58351@LiaquatDELL>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

NO

Not really needed in my opinion, generally the person (i.e. an
administrator) setting up the OCSP client software will know upfront the
capabilities of the responders that will be accessed by the OCSP client
and therefore configure the client accordingly (i.e. with or without
nonce).  

In the case that OCSP clients are dealing with random, previously
unknown OCSP responders, then such an error code may have some use in
pin-pointing the problem from the various things that may go wrong.  But
I don't think the limited value it adds is worth the change.  

Anyway, I agree with Denis, a summary would be useful though...in case I
have missed something important somewhere down the line...

Regards,
LK

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Michael Myers
Sent: 15 October 2003 22:03
To: [e-mail]
Subject: POLL: Nonce-specific error code for OCSP


All,

I recently received permission from the chairs to poll the WG
against the following question.

Should we standardize an OCSP *V1* error code that enables a
responder to indicate its inability to respond to nonced
requests?

Please respond with either YES or NO.

Mike






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G8mnI7066237 for <[e-mail]>; Thu, 16 Oct 2003 01:48:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9G8mmUF066235 for ietf-pkix-bks; Thu, 16 Oct 2003 01:48:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9G8mkI7066192 for <[e-mail]>; Thu, 16 Oct 2003 01:48:47 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 5372 invoked by uid 1649); 16 Oct 2003 08:48:41 -0000
Date: 16 Oct 2003 08:48:41 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
Subject: Re: POLL: Nonce-specific error code for OCSP
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Should we standardize an OCSP *V1* error code that enables a
> responder to indicate its inability to respond to nonced
> requests?
> 
> Please respond with either YES or NO.

NO

Rationale: 
My first idea was to say: if it is OPTIONAL for the responder to use that error code it is ok. But in fact even the OPTIONAL inclusion harms the security of the protocol, as an attacker can fool clients into believing a particular OCSP-Responder would not support nonces, when in fact it does.

My conclusion: Dont include such an error code, due to security reasons. If other reasons (yet unknown to me) overrule these concerns make the use of this error code OPTIONAL for responders to allow compatibility with existing installations and not to harm the functionality of the protocol.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G7YHI7044158 for <[e-mail]>; Thu, 16 Oct 2003 00:34:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9G7YGB8044156 for ietf-pkix-bks; Thu, 16 Oct 2003 00:34:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9G7YEI7044136 for <[e-mail]>; Thu, 16 Oct 2003 00:34:15 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA11606; Thu, 16 Oct 2003 09:40:13 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA18916; Thu, 16 Oct 2003 09:35:49 +0200
Message-ID: <[e-mail]>
Date: Thu, 16 Oct 2003 09:34:09 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: POLL: Nonce-specific error code for OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9G7YGI7044149
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

> All,

> I recently received permission from the chairs to poll the WG
> against the following question.

> Should we standardize an OCSP *V1* error code that enables a
> responder to indicate its inability to respond to nonced
> requests?

> Please respond with either YES or NO.

I would suggest to you provide a resumé of the advantages of this new error 
code (and disadvantages if not supported), so that people do not have to 
look back at that long thread on that topic to make up their opinion.

Denis

> Mike






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FMVbI7094449 for <[e-mail]>; Wed, 15 Oct 2003 15:31:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FMVbRh094448 for ietf-pkix-bks; Wed, 15 Oct 2003 15:31:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FMVZI7094443 for <[e-mail]>; Wed, 15 Oct 2003 15:31:36 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h9FMVWTX017046; Wed, 15 Oct 2003 18:31:32 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002017bbb37a59c2cb@[128.89.89.75]>
Date: Wed, 15 Oct 2003 18:29:24 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft-ietf-pkix-x509-ipaddr-as-extn-03.txt
Cc: russ housley <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The subject ID was revised in response to comments during last call, 
and the new version was posted late last month, so I am now 
forwarding it to Russ Housely for IESG review.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FKxeI7091572 for <[e-mail]>; Wed, 15 Oct 2003 13:59:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9FKxeCP091571 for ietf-pkix-bks; Wed, 15 Oct 2003 13:59:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9FKxcI7091566 for <[e-mail]>; Wed, 15 Oct 2003 13:59:38 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h9FKxet09803 for <[e-mail]>; Wed, 15 Oct 2003 13:59:40 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: POLL: Nonce-specific error code for OCSP
Date: Wed, 15 Oct 2003 14:02:39 -0700
Message-ID: <[e-mail]>
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: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I recently received permission from the chairs to poll the WG
against the following question.

Should we standardize an OCSP *V1* error code that enables a
responder to indicate its inability to respond to nonced
requests?

Please respond with either YES or NO.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AHkRZA002794 for <[e-mail]>; Fri, 10 Oct 2003 10:46:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9AHkR6X002793 for ietf-pkix-bks; Fri, 10 Oct 2003 10:46:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mgate11.so-net.ne.jp (mgate11.so-net.ne.jp [210.139.254.158]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AHkOZA002784 for <[e-mail]>; Fri, 10 Oct 2003 10:46:25 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.dc5.so-net.ne.jp (mspool14.so-net.ne.jp [210.139.248.14]) by mgate11.so-net.ne.jp  with ESMTP id h9AHkOH15444; Sat, 11 Oct 2003 02:46:25 +0900 (JST)
Received: from [192.168.1.14] (eatky65-p17.hi-ho.ne.jp [219.105.30.18]) by mail.dc5.so-net.ne.jp  with ESMTP id h9AHkOI28716; Sat, 11 Oct 2003 02:46:24 +0900 (JST)
Date: Sat, 11 Oct 2003 02:46:07 +0900
From: Nakagawa <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Subject: Re: request for reviewing our interoperability experiment report
Cc: <[e-mail]>
In-Reply-To: <029f01c38745$5608db20$0500a8c0@arport>
References: <[e-mail]> <029f01c38745$5608db20$0500a8c0@arport>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Rundgren-san,

Thank you for your comment, and very sorry for my late reply.
I conveyed your opinion to our team and am waiting for their comment.
If I get any, I'll post it to this mailing list ASAP. Anyway, we'll take
your comment into consideration when we have chance to revise
the Final Report.

Best Regards,

Nakagawa
Japan PKI Forum

----------------------- Original Message -----------------------
On Tue, 30 Sep 2003 13:23:43 +0200
"Anders Rundgren" <[e-mail]> wrote:

> 
> Dear Nakagawa-San,
> May I offer some comments not so much on the report itself, but
> on the architectures that you are working with?  The described
> CA structures represent one of three IMO entirely different ways
> to apply PKI:
> 
> 1. The "Classic".  Often using Cross-Certification (CC) and is fairly complex. 
>     Used by the FED-PKI and the PKIs described in the report.  Adding
>     CP extensions as "application trust filters", things get even more complex
>     to scale-up as the extensions are (and will likely continue to be) never
>     agreed upon except within certain "communities".  It is interesting to
>     note that AFAIK, no commercial TTP CA make their
>     issuance depending on CP extensions.  I.e., they all use the
>    "universal issuing formula" CA <=> Policy.
> 
> 2. Relying-party-only.   RP=CA.  Limited interoperability concerns but
>     potentially awkward out-of-band RA-arrangements when the number
>     of external partners increase.
> 
> 3. The bank-model PKI [*].  Builds on legacy IT architectures and is
>     simpler (but magnitudes more flexible) compared to the "Classic".
> Short "promotional" description: http://www.x-obi.com/OBI400/b2bsign.pdf
> Long(-winding) description: http://www.x-obi.com/OBI400/pki4org.pdf
> 
> Regarding interoperability I noted that you did not mention the four-corner
> model which if I'm not misinformed possibly to be used by the coming Japanese
> government PKI hosted by Identrus.  This system eliminates CC and
> interoperability (as it is a closed trust-network) but dramatically
> complicates RP software handling as there are no standards for
> managing independent (they all are) four-corner trust-networks.
> Most of these competing trust-networks require you to pay license
> fees and only use certified software.  This is how the Swedish
> banks currently operate.  A short [negative] description of four-corner:
> http://www.x-obi.com/OBI400/e-government-ID-A.Rundgren.pdf
> 
> Press-release indicating that the Japanese government indeed
> is considering supporting four-corner models:
> http://www.identrus.com/company/press_releases/release_030717.html
> 
> Regards
> Anders Rundgren
> 
> *] My participation in more or less related standards:
> http://shibboleth.internet2.edu/minutes/SHIB-05-Sept-2001.html
> 
> 
> ----- Original Message ----- 
> From: "Nakagawa" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> Sent: Monday, September 29, 2003 11:50
> Subject: request for reviewing our interoperability experiment report
> 
> 
> 
> Dear PKIX list members,
> 
> Korea PKI Forum, PKI Forum Singapore, Chinese Taipei PKI Forum, and Japan
> PKI Forum are pleased to announce the completion of the Final Report for
> the Experiment in PKI Interoperability in Asia region in 2002. These
> four countries/areas have been conducting the Experiment in PKI
> interoperability since 2001, and compiled the first report for the 2001
> experiment in the middle of 2002. A report compiled this time is
> extended version of the previous one. 
> 
> In 2002, we have conducted 3 experiments as follows: 
> 
> 1) CA-CA Interoperability Experiment with Cross Certification / Cross
> Recognition models;
> 
> 2) Path Processing Experiment intending to Resolve the certificate path
> processing issues of repository by clarifying the path processing logic
> described in RFC3280;
> 
> 3) PKCS#11 Experiment tempting to approach PKI application
> interoperability using a commonly defined API (application interface).
> The Final Report contains the recommended technical specifications and
> the lessons learnt, which are valuable for CA operators, VA (validation
> authority) and application developers when dealing with relevant
> interoperability matters.
> 
> In addition to this overall project result document, other five documents
> were developed as appendixes, which are: 
> - Appendix 1. IWG Recommended Profiles
> - Appendix 2. CA-CA Interoperability Interface Specification for
> experiment
> - Appendix 3. Certificate Path Processing Implementation Guideline
> - Appendix 4. Certificate Path Processing Testing Guideline
> - Appendix 5. PKCS#11 Testing
> 
> It will be highly appreciated if IETF members examine the
> report and let us know your thoughts/comments.
> You can download the report and the appendix from:
> 
> Achieving PKI Interoperability 2003 -Results of the JKST-IWG Interoperability project-
> http://www.japanpkiforum.jp/shiryou/IWG_2002/FinalReport2003-Version1.0.pdf
> Appendix
> http://www.japanpkiforum.jp/shiryou/IWG_2002/Appendix.pdf
> 
> Regards,
> 
> -- 
> Hiroyuki Nakagawa
> Japan PKI Forum




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94EiUKP036402 for <[e-mail]>; Sat, 4 Oct 2003 07:44:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h94EiTHn036401 for ietf-pkix-bks; Sat, 4 Oct 2003 07:44:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h94EiSKP036396 for <[e-mail]>; Sat, 4 Oct 2003 07:44:28 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h94EiSt68829; Sat, 4 Oct 2003 07:44:28 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Tim Polk" <[e-mail]>, "Carlisle Adams" <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Sat, 4 Oct 2003 07:47:48 -0700
Message-ID: <[e-mail]>
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 V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well, it certainly wasn't in *my* mind at the time that nonces,
if used, would be ignored.  To my recollection, the discussions
between Carlisle and myself that lead to their definition were
quite robust on the point.

Indeed, as the poll indicates something close to 11 of 12 of
client side implementors treat (or can treat) the practice as an
error.  So it's not like this is a great revelation to anybody.
Yes, extensions are optional.  But extensions may have
additional semantics associated with their use.  The fact that
the definition of the nonce extension does not is where we got
started with a view towards clarifying original intent.

Since nonces break caching, don't use nonces in a cached
environment.  Send a non-nonced response anyway due to
server-side lack of control on the client side?  Maybe.  If the
chairs and the AD are comfortable allowing the IETF to
standardize the practice, I'd be happy to oblige.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9425hKP052611 for <[e-mail]>; Fri, 3 Oct 2003 19:05:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h9425hOM052610 for ietf-pkix-bks; Fri, 3 Oct 2003 19:05:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h9425fKP052605 for <[e-mail]>; Fri, 3 Oct 2003 19:05:41 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd09.aul.t-online.de  by mailout06.sul.t-online.com with smtp  id 1A5bna-0005SR-00; Sat, 04 Oct 2003 04:05:34 +0200
Received: from hagen (SaX0s2ZaYeJJ2sG3sVLuEk+3KdZBM5ro57Rv403kD4gKiu7k+BKCgf@[217.228.236.213]) by fmrl09.sul.t-online.com with esmtp id 1A5bnY-1ej8nA0; Sat, 4 Oct 2003 04:05:32 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Jean-Marc Desperrier'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Sat, 4 Oct 2003 04:05:33 +0200
Organization: SyTrust
Message-ID: <001b01c38a1b$fee079a0$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >>- re-assert that it is not conformant to RFC2560 to send back
> >>a response 
> >>without to nonce to a request requiring a nonce (it might 
> >>change in OCSPv2)
> > 
> > The RfC states: "[A request includes] [...] optional 
> extensions which 
> > MAY be processed by the OCSP Responder".
> 
> I don't know.
> This is not in line with RFC3280 definition of extensions, in 
> which if 
> you *do* recognize an extension, you have to treat it 
> correctly and not 
> simply ignore it.
> With that definition if you implement RFC2560, you can say I 
> don't know 
> what id-pkix-ocsp-nonce means so I don't care about it, because it's 
> defined in the standard.

You are partly right for RfC3280 - while it in fact lists some
extensions that SHALL be recognized by CAs/applications, in general
extension are optional. The exact wording of RfC3280 is:

"A certificate using system MUST reject the certificate if it encounters
a critical extension it does not recognize; however, a non-critical
extension MAY be ignored if it is not recognized. [...] [List of
extensions CAs and Applications SHOULD recognize] Support for the
remaining extensions is OPTIONAL." [nearly same wording for CRLs]

Nevertheless the wording of RfC3280 and RfC2560 is very different. If we
apply the rationale behind RfC3280 to RfC2560, we should allow a client
to mark his nonce-extension critical, thus indicating that it does not
wish that any responder ignores the nonce. But currently RfC2560 states
clearly: 

"Support for any specific extension is OPTIONAL. The critical flag
SHOULD NOT be set for any of them."

Allowing an extension (e.g. the nonce-extension) to be critical would be
a change to RfC2560. I would really like such a change, but as Ambarish
already pointed out, this may put an unwanted semantic into the requests
of some existing clients out there. As these clients adhere to RfC2560,
the nonce is not critical - thus they would indicate that a nonceless
response is ok for them.

Remark: With this whole system, we have not yet solved the problem
adressed by David's proposal: A client wants to know securely if a
response without nonce was generated by an OCSP-responder not supporting
nonces or by an OCSP-responder normally being able to generate nonces. 

-- 
Florian Oelmaier
SyTrust





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93MsxKP048151 for <[e-mail]>; Fri, 3 Oct 2003 15:55:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93Msxs5048150 for ietf-pkix-bks; Fri, 3 Oct 2003 15:54:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93MsxKP048145 for <[e-mail]>; Fri, 3 Oct 2003 15:54:59 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.10/) with ESMTP id h93MsuFI029851; Fri, 3 Oct 2003 15:54:56 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <TTLKZ9G9>; Fri, 3 Oct 2003 15:54:55 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Michael Myers'" <[e-mail]>, "'Jean-Marc Desperrier'" <[e-mail]>, [e-mail]
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 15:54:49 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes, I have an issue with "re-assert[ing] that it is not conformant to
RFC2560 to send back a response without to nonce to a request requiring a
nonce"

You can't re-assert something that was never asserted in the first place.
The current spec does not mandate that servers support extensions in OCSP
requests. (as Florian pointed out in a recent email)  Mandating that servers
MUST respond to a nonce extension would make currently compliant responders
non-compliant.   Not good...

Alex


> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Friday, October 03, 2003 10:35 AM
> To: 'Michael Myers'; 'Jean-Marc Desperrier'; [e-mail]
> Subject: RE: OCSP response pre-production
> 
> 
> 
> 
> Yup, sounds good to me. Is there rough concensus that this is what
> folks want? Anybody with a strong opinion to the contrary, please
> pipe up now.
> 
> Regards,
> Ambarish
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Michael Myers
> > Sent: Friday, October 03, 2003 9:17 AM
> > To: Jean-Marc Desperrier; [e-mail]
> > Subject: RE: OCSP response pre-production
> > 
> > 
> > 
> > 
> > This works for me, especially the part about getting 
> > definitive on 2560 as it stands.  Ambarish?
> > 
> > Mike
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]]On Behalf Of Jean-Marc 
> > Desperrier
> > > Sent: Friday, October 03, 2003 8:09 AM
> > > To: [e-mail]
> > > Subject: Re: OCSP response pre-production
> > >
> > >
> > >
> > > Frank Balluffi wrote:
> > > > My preference would be to define an extension (e.g., via an 
> > > > informational RFC) that can be used with v1 bits on
> > > the wire, and
> > > > then to formally incorporate the extension into v2.
> > > Again, if a
> > > > strong case can be made for v2 to use a different
> > > mechanism (than the
> > > > extension defined above), I am OK with that.
> > >
> > > I know understand better the case against the
> > > round-trip error discovery
> > > solution without a signed assertion from server.
> > >
> > > I think the above solution is something everybody can
> > > agree on, and stop
> > > discussing the point for ever.
> > >
> > > So can everybody agree on creating an informationnal
> > > RFC about how to
> > > handle cache response in OCSP v1 that would :
> > >
> > > - define an extension that enable a responder to
> > > assert the answer is a
> > > cached answer and not an answer to a nonce-less request
> > >
> > > - [MAYBE] define a value for that extension that says
> > > this answer does
> > > not include a nonce, but that the server can provide
> > > one if requested
> > >
> > > - re-assert that it is not conformant to RFC2560 to
> > > send back a response
> > > without to nonce to a request requiring a nonce (it
> > > might change in OCSPv2)
> > >
> > > - precise what error amongst the already defined one
> > > the OCSP server
> > > should send back when receiving a nonce if it can not
> > > send one back
> > >
> > > - describe that a client who wants the best possible
> > > answer can :
> > > * Ask for a nonce
> > > * Receive an error
> > > * Ask without nonce
> > > * Receive an answer that includes the extension that
> > > the server can not
> > > able to include nonces in answers.
> > >
> > > - describe another possible solution :
> > > * Don't ask for a nonce
> > > * Receive an answer that includes the extension that
> > > the server can
> > > include nonces in answers.
> > > * Ask with a nonce, because I want the very best I can have.
> > >
> > > The second solution might be better if the servers
> > > that send back cached
> > > answer have a very heavy load and want to avoid the 
> > round-trip, whilst
> > > the one that are ready to provide nonces are more
> > > likely not to have a
> > > problem with round-trips.
> > >
> > > An evolution could then be included in OCSPv2 to
> > > avoid the round-trip
> > > completely.
> > >
> > >
> > 
> > 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93LN8KP044884 for <[e-mail]>; Fri, 3 Oct 2003 14:23:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93LN8G3044883 for ietf-pkix-bks; Fri, 3 Oct 2003 14:23:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93LN6KP044877 for <[e-mail]>; Fri, 3 Oct 2003 14:23:07 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd09.aul.t-online.de  by mailout03.sul.t-online.com with smtp  id 1A5XOA-0003bL-03; Fri, 03 Oct 2003 23:23:02 +0200
Received: from hagen (rxbHHTZQ8ecYD64RXHTXxLiTluHypgqgB+Wv1TrxoGNl49NktwSWk-@[217.228.236.213]) by fmrl09.sul.t-online.com with esmtp id 1A5XO8-0WOTDc0; Fri, 3 Oct 2003 23:23:00 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Jean-Marc Desperrier'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 23:23:00 +0200
Organization: SyTrust
Message-ID: <001701c389f4$861f0030$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> What would you think if it'd also define an extension that the client 
> can use in a request including a nonce, in order to indicate it will 
> accept an answer without a nonce if it includes the 
> pre-produced extension.

If we do that, I agree with your course, Jean-Marc. Otherwise I would
feel strongly against it. In any case I would vote to go with Davids
proposal - it seems more simple to me while accomplishing the same task
with additional security.

> The server would be breaking RFC 2560 by sending back the 
> pre-produced 
> answer, but only with a client that has explicitly indicated it is 
> expecting this behaviour.

Once again: RfC2560 allows sending of nonceless responses to nonced
requests. It clearly states that processing of every extension (and
"nonce" is an extension) is optional for both responder and client. And
OPTIONAL is clearly defined. So if we define that request-extension, the
responder would be fully on the ground of RfC2560. 

In fact I would bet that currently nearly all caching servers send back
nonceless responses to nonced requests - as this is what the RfC seems
to suggest in ist current wording. At least this is what our responder
does when configured for caching.

-- 
Florian Oelmaier
SyTrust





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93K00KP041348 for <[e-mail]>; Fri, 3 Oct 2003 13:00:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93K00Jb041347 for ietf-pkix-bks; Fri, 3 Oct 2003 13:00:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.205]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93JxwKP041337 for <[e-mail]>; Fri, 3 Oct 2003 12:59:58 -0700 (PDT) (envelope-from [e-mail])
Received: from alussinan.org (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft6.fr.colt.net with ESMTP id h93JxuO28332 for <[e-mail]>; Fri, 3 Oct 2003 21:59:56 +0200
Message-ID: <[e-mail]>
Date: Fri, 03 Oct 2003 21:59:54 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031002
X-Accept-Language: en, fr, en-us, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP response pre-production
References: <000001c389dd$262fcb30$4228a8c0@hagen>
In-Reply-To: <000001c389dd$262fcb30$4228a8c0@hagen>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Florian Oelmaier wrote:
>>- re-assert that it is not conformant to RFC2560 to send back 
>>a response 
>>without to nonce to a request requiring a nonce (it might 
>>change in OCSPv2)
> 
> The RfC states: "[A request includes] [...] optional extensions which
> MAY be processed by the OCSP Responder". 

I don't know.
This is not in line with RFC3280 definition of extensions, in which if 
you *do* recognize an extension, you have to treat it correctly and not 
simply ignore it.
With that definition if you implement RFC2560, you can say I don't know 
what id-pkix-ocsp-nonce means so I don't care about it, because it's 
defined in the standard.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93Ia4KP037476 for <[e-mail]>; Fri, 3 Oct 2003 11:36:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93Ia4L0037475 for ietf-pkix-bks; Fri, 3 Oct 2003 11:36:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93Ia0KP037467 for <[e-mail]>; Fri, 3 Oct 2003 11:36:02 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd09.aul.t-online.de  by mailout10.sul.t-online.com with smtp  id 1A5UmW-0005U2-09; Fri, 03 Oct 2003 20:36:00 +0200
Received: from hagen (E2touuZeoeFZXU4Uo7qdQY4gUx9woZ24EaxuugIcWefj2uCcVlUh8B@[217.228.236.213]) by fmrl09.sul.t-online.com with esmtp id 1A5UmD-0OfS1Q0; Fri, 3 Oct 2003 20:35:41 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Jean-Marc Desperrier'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 20:35:41 +0200
Organization: SyTrust
Message-ID: <000001c389dd$262fcb30$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> - re-assert that it is not conformant to RFC2560 to send back 
> a response 
> without to nonce to a request requiring a nonce (it might 
> change in OCSPv2)

The RfC states: "[A request includes] [...] optional extensions which
MAY be processed by the OCSP Responder". With the clear definition of
MAY according to RfC 2119:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

When writing such an informational RfC we also have to clarify that
extension processing is not optional anymore with this change (as every
responder MUST detect a nonce).

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93HqkKP035237 for <[e-mail]>; Fri, 3 Oct 2003 10:52:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93HqkX8035236 for ietf-pkix-bks; Fri, 3 Oct 2003 10:52:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft2.fr.colt.net (smtp-ft2.fr.colt.net [213.41.78.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93HqiKP035231 for <[e-mail]>; Fri, 3 Oct 2003 10:52:45 -0700 (PDT) (envelope-from [e-mail])
Received: from alussinan.org (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft2.fr.colt.net with ESMTP id h93Hqg610137 for <[e-mail]>; Fri, 3 Oct 2003 19:52:42 +0200
Message-ID: <[e-mail]>
Date: Fri, 03 Oct 2003 19:52:41 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031002
X-Accept-Language: en, fr, en-us, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP response pre-production
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Myers wrote:
> This works for me, especially the part about getting definitive
> on 2560 as it stands.  Ambarish?

I've been thinking about something more, I hope it doesn't reopen the 
whole can of worms.

What would you think if it'd also define an extension that the client 
can use in a request including a nonce, in order to indicate it will 
accept an answer without a nonce if it includes the pre-produced extension.

The server would be breaking RFC 2560 by sending back the pre-produced 
answer, but only with a client that has explicitly indicated it is 
expecting this behaviour.

This, if acceptable, would enable to fully avoid the round-trip with 
compatible servers.
Legacy servers would send back an error to this kind of request if they 
can not supply a nonce, which does not break the expected behaviour.

>> - define an extension that enable a responder to
>> assert the answer is a
>> cached answer and not an answer to a nonce-less request

I'll correct myself : "is a pre-produced answer and this server can not 
successfully answer requests requiring a nonce."



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93HZKKP034446 for <[e-mail]>; Fri, 3 Oct 2003 10:35:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93HZKpB034445 for ietf-pkix-bks; Fri, 3 Oct 2003 10:35:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93HZJKP034436 for <[e-mail]>; Fri, 3 Oct 2003 10:35:19 -0700 (PDT) (envelope-from [e-mail])
Received: from AMBARISHW2K (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id h93HYa4c002520; Fri, 3 Oct 2003 10:34:36 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "'Jean-Marc Desperrier'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 10:34:40 -0700
Message-ID: <000201c389d4$a05e42f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yup, sounds good to me. Is there rough concensus that this is what
folks want? Anybody with a strong opinion to the contrary, please
pipe up now.

Regards,
Ambarish

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Michael Myers
> Sent: Friday, October 03, 2003 9:17 AM
> To: Jean-Marc Desperrier; [e-mail]
> Subject: RE: OCSP response pre-production
> 
> 
> 
> 
> This works for me, especially the part about getting 
> definitive on 2560 as it stands.  Ambarish?
> 
> Mike
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]On Behalf Of Jean-Marc 
> Desperrier
> > Sent: Friday, October 03, 2003 8:09 AM
> > To: [e-mail]
> > Subject: Re: OCSP response pre-production
> >
> >
> >
> > Frank Balluffi wrote:
> > > My preference would be to define an extension (e.g., via an 
> > > informational RFC) that can be used with v1 bits on
> > the wire, and
> > > then to formally incorporate the extension into v2.
> > Again, if a
> > > strong case can be made for v2 to use a different
> > mechanism (than the
> > > extension defined above), I am OK with that.
> >
> > I know understand better the case against the
> > round-trip error discovery
> > solution without a signed assertion from server.
> >
> > I think the above solution is something everybody can
> > agree on, and stop
> > discussing the point for ever.
> >
> > So can everybody agree on creating an informationnal
> > RFC about how to
> > handle cache response in OCSP v1 that would :
> >
> > - define an extension that enable a responder to
> > assert the answer is a
> > cached answer and not an answer to a nonce-less request
> >
> > - [MAYBE] define a value for that extension that says
> > this answer does
> > not include a nonce, but that the server can provide
> > one if requested
> >
> > - re-assert that it is not conformant to RFC2560 to
> > send back a response
> > without to nonce to a request requiring a nonce (it
> > might change in OCSPv2)
> >
> > - precise what error amongst the already defined one
> > the OCSP server
> > should send back when receiving a nonce if it can not
> > send one back
> >
> > - describe that a client who wants the best possible
> > answer can :
> > * Ask for a nonce
> > * Receive an error
> > * Ask without nonce
> > * Receive an answer that includes the extension that
> > the server can not
> > able to include nonces in answers.
> >
> > - describe another possible solution :
> > * Don't ask for a nonce
> > * Receive an answer that includes the extension that
> > the server can
> > include nonces in answers.
> > * Ask with a nonce, because I want the very best I can have.
> >
> > The second solution might be better if the servers
> > that send back cached
> > answer have a very heavy load and want to avoid the 
> round-trip, whilst
> > the one that are ready to provide nonces are more
> > likely not to have a
> > problem with round-trips.
> >
> > An evolution could then be included in OCSPv2 to
> > avoid the round-trip
> > completely.
> >
> >
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93GDEKP029038 for <[e-mail]>; Fri, 3 Oct 2003 09:13:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93GDEpW029037 for ietf-pkix-bks; Fri, 3 Oct 2003 09:13:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93GDDKP029032 for <[e-mail]>; Fri, 3 Oct 2003 09:13:13 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h93GD9t28189; Fri, 3 Oct 2003 09:13:09 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 09:16:31 -0700
Message-ID: <[e-mail]>
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)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This works for me, especially the part about getting definitive
on 2560 as it stands.  Ambarish?

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Jean-Marc Desperrier
> Sent: Friday, October 03, 2003 8:09 AM
> To: [e-mail]
> Subject: Re: OCSP response pre-production
>
>
>
> Frank Balluffi wrote:
> > My preference would be to define an extension (e.g., via an
> > informational RFC) that can be used with v1 bits on
> the wire, and
> > then to formally incorporate the extension into v2.
> Again, if a
> > strong case can be made for v2 to use a different
> mechanism (than the
> > extension defined above), I am OK with that.
>
> I know understand better the case against the
> round-trip error discovery
> solution without a signed assertion from server.
>
> I think the above solution is something everybody can
> agree on, and stop
> discussing the point for ever.
>
> So can everybody agree on creating an informationnal
> RFC about how to
> handle cache response in OCSP v1 that would :
>
> - define an extension that enable a responder to
> assert the answer is a
> cached answer and not an answer to a nonce-less request
>
> - [MAYBE] define a value for that extension that says
> this answer does
> not include a nonce, but that the server can provide
> one if requested
>
> - re-assert that it is not conformant to RFC2560 to
> send back a response
> without to nonce to a request requiring a nonce (it
> might change in OCSPv2)
>
> - precise what error amongst the already defined one
> the OCSP server
> should send back when receiving a nonce if it can not
> send one back
>
> - describe that a client who wants the best possible
> answer can :
> * Ask for a nonce
> * Receive an error
> * Ask without nonce
> * Receive an answer that includes the extension that
> the server can not
> able to include nonces in answers.
>
> - describe another possible solution :
> * Don't ask for a nonce
> * Receive an answer that includes the extension that
> the server can
> include nonces in answers.
> * Ask with a nonce, because I want the very best I can have.
>
> The second solution might be better if the servers
> that send back cached
> answer have a very heavy load and want to avoid the
> round-trip, whilst
> the one that are ready to provide nonces are more
> likely not to have a
> problem with round-trips.
>
> An evolution could then be included in OCSPv2 to
> avoid the round-trip
> completely.
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93F9NKP025166 for <[e-mail]>; Fri, 3 Oct 2003 08:09:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93F9NIo025165 for ietf-pkix-bks; Fri, 3 Oct 2003 08:09:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft2.fr.colt.net (smtp-ft2.fr.colt.net [213.41.78.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93F9LKP025158 for <[e-mail]>; Fri, 3 Oct 2003 08:09:22 -0700 (PDT) (envelope-from [e-mail])
Received: from alussinan.org (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft2.fr.colt.net with ESMTP id h93F9H617164 for <[e-mail]>; Fri, 3 Oct 2003 17:09:17 +0200
Message-ID: <[e-mail]>
Date: Fri, 03 Oct 2003 17:09:16 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030811
X-Accept-Language: en, fr, en-us, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP response pre-production
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Frank Balluffi wrote:
> My preference would be to define an extension (e.g., via an 
> informational RFC) that can be used with v1 bits on the wire, and
> then to formally incorporate the extension into v2. Again, if a
> strong case can be made for v2 to use a different mechanism (than the
> extension defined above), I am OK with that.

I know understand better the case against the round-trip error discovery 
solution without a signed assertion from server.

I think the above solution is something everybody can agree on, and stop 
discussing the point for ever.

So can everybody agree on creating an informationnal RFC about how to 
handle cache response in OCSP v1 that would :

- define an extension that enable a responder to assert the answer is a 
cached answer and not an answer to a nonce-less request

- [MAYBE] define a value for that extension that says this answer does 
not include a nonce, but that the server can provide one if requested

- re-assert that it is not conformant to RFC2560 to send back a response 
without to nonce to a request requiring a nonce (it might change in OCSPv2)

- precise what error amongst the already defined one the OCSP server 
should send back when receiving a nonce if it can not send one back

- describe that a client who wants the best possible answer can :
* Ask for a nonce
* Receive an error
* Ask without nonce
* Receive an answer that includes the extension that the server can not 
able to include nonces in answers.

- describe another possible solution :
* Don't ask for a nonce
* Receive an answer that includes the extension that the server can 
include nonces in answers.
* Ask with a nonce, because I want the very best I can have.

The second solution might be better if the servers that send back cached 
answer have a very heavy load and want to avoid the round-trip, whilst 
the one that are ready to provide nonces are more likely not to have a 
problem with round-trips.

An evolution could then be included in OCSPv2 to avoid the round-trip 
completely.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93E8kKP022157 for <[e-mail]>; Fri, 3 Oct 2003 07:08:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93E8kO9022156 for ietf-pkix-bks; Fri, 3 Oct 2003 07:08:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imr5.us.db.com (imr5.us.db.com [160.83.65.196]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93E8jKP022151 for <[e-mail]>; Fri, 3 Oct 2003 07:08:45 -0700 (PDT) (envelope-from [e-mail])
Received: from sdbo1005.db.com by imr5.us.db.com  id h93E8hGa019455; Fri, 3 Oct 2003 10:08:43 -0400 (EDT)
Subject: RE: OCSP response pre-production
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Fri, 3 Oct 2003 10:08:41 -0400
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.12  |February 13, 2003) at 10/03/2003 10:08:42 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please disregard "Again," below. It referred to something I deleted before sending.

Frank



                                                                                                                                           
                      "Frank Balluffi"                                                                                                     
                      <frank.balluffi+exter        To:       [e-mail]                                                              
                      [e-mail]>                  cc:       [e-mail]                                                             
                      Sent by:                     Subject:  RE: OCSP response pre-production                                              
                      owner-ietf-pkix@mail.                                                                                                
                      imc.org                                                                                                              
                                                                                                                                           
                                                                                                                                           
                      10/03/2003 09:11 AM                                                                                                  
                                                                                                                                           
                                                                                                                                           






Mike,

My preference would be to define an extension (e.g., via an informational RFC) that can be used with v1 bits on the wire, and then to formally incorporate the extension into v2. Again, if a strong case can be made for v2 to use a different mechanism (than the extension defined above), I am OK with that.

I hope this answers your question.

Frank




                      "Michael Myers"
                      <[e-mail]        To:       Frank Balluffi/NewYork/DBNA/DeuBa@DBNA, <[e-mail]>
                      >                        cc:       "David Engberg" <[e-mail]>, <[e-mail]>
                      Sent by:                 Subject:  RE: OCSP response pre-production
                      owner-ietf-pkix@m
                      ail.imc.org


                      10/02/2003 06:08
                      PM








> -----Original Message-----
> From: Frank Balluffi
>
> . . .
>
> I too like the proposal to use a flag or an
> extension. Perhaps an extension could say the
> equivalent of, "This is a cached response."

Frank,

Would you object the v1/v2 dual paths as means of getting this
into place?

Mike







--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.







--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93DJ5KP019898 for <[e-mail]>; Fri, 3 Oct 2003 06:19:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93DJ5Zb019897 for ietf-pkix-bks; Fri, 3 Oct 2003 06:19:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93DJ3KP019890 for <[e-mail]>; Fri, 3 Oct 2003 06:19:03 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA59605 for <[e-mail]>; Fri, 3 Oct 2003 09:18:53 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt
Date: Fri, 3 Oct 2003 09:17:55 -0400
Organization: Gemini Security Solutions, Inc.
Message-ID: <00b501c389b0$c7babfa0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

To save everyone the trouble of trying to read through our entire
internet draft a second time, the following lists outline the main
changes made in the document since version 00.

Overall changes:
- made certain terminology more consistent ("certification 
   path" throughout the document instead of "certificate path", 
   "cert path", etc.)
- softened the tone; made it clear that the document provides 
   informational recommendations and does not prescribe a 
   particular method for certification path building
- removed statements on the document providing guidance based 
   on "best practices" but instead explicitly defined the 
   motivation and purpose behind the document, as well as the 
   criteria that led to the guidance provided. 
- removed some non-ascii characters that had snuck in

Specific changes:
- Thoroughly updated section 1.1 (Motivation) and 1.2 (Purpose)
- updated terminology section to include a few additional terms
- updated mesh PKI figure to better differentiate it from other
   structures
- included a section (2.2) that clearly identifies the authors'
   criteria for a path building implementation
- broke up section 2.4 (How to Build a Certification Path) with
   some subsections
- added section 3.3 (Representing the Decision Tree 
   Programmatically)
- updated section 3.5 to include additional information about 
   the sorting methods that follow.  Sorting methods are no 
   longer called "rules".
- added section 5.4 (Distinguished Name Encoding)
- added section 6.3 (Subject Information Access)

Cheers,

--Peter Hesse

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Thursday, October 02, 2003 10:51 AM
To: IETF-Announce:; [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt


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:

                          Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow et al.
	Filename	: draft-ietf-pkix-certpathbuild-01.txt
	Pages		: 67
	Date		: 2003-10-2
	
This document was written to provide guidance and recommendations to 
developers building X.509 public-key certification paths within their 
applications.  By following the guidance and recommendations defined 
in this document, an application developer is more likely to develop 
a robust X.509 certificate enabled application that can build valid 
certification paths across a wide range of PKI environments.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

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-certpathbuild-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-certpathbuild-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.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93DBLKP019417 for <[e-mail]>; Fri, 3 Oct 2003 06:11:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93DBLVu019416 for ietf-pkix-bks; Fri, 3 Oct 2003 06:11:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imr5.us.db.com (imr5.us.db.com [160.83.65.196]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93DBJKP019408 for <[e-mail]>; Fri, 3 Oct 2003 06:11:20 -0700 (PDT) (envelope-from [e-mail])
Received: from sdbo1005.db.com by imr5.us.db.com  id h93DBIGa025435; Fri, 3 Oct 2003 09:11:18 -0400 (EDT)
Subject: RE: OCSP response pre-production
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Fri, 3 Oct 2003 09:11:15 -0400
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.12  |February 13, 2003) at 10/03/2003 09:11:18 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

My preference would be to define an extension (e.g., via an informational RFC) that can be used with v1 bits on the wire, and then to formally incorporate the extension into v2. Again, if a strong case can be made for v2 to use a different mechanism (than the extension defined above), I am OK with that.

I hope this answers your question.

Frank



                                                                                                                                       
                      "Michael Myers"                                                                                                  
                      <[e-mail]        To:       Frank Balluffi/NewYork/DBNA/DeuBa@DBNA, <[e-mail]>                  
                      >                        cc:       "David Engberg" <[e-mail]>, <[e-mail]>                    
                      Sent by:                 Subject:  RE: OCSP response pre-production                                              
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      10/02/2003 06:08                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       






> -----Original Message-----
> From: Frank Balluffi
>
> . . .
>
> I too like the proposal to use a flag or an
> extension. Perhaps an extension could say the
> equivalent of, "This is a cached response."

Frank,

Would you object the v1/v2 dual paths as means of getting this
into place?

Mike







--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93BEEKP013916 for <[e-mail]>; Fri, 3 Oct 2003 04:14:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93BEEGR013915 for ietf-pkix-bks; Fri, 3 Oct 2003 04:14:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93BECKP013909 for <[e-mail]>; Fri, 3 Oct 2003 04:14:13 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd09.aul.t-online.de  by mailout11.sul.t-online.com with smtp  id 1A5Nsw-0001K2-01; Fri, 03 Oct 2003 13:14:10 +0200
Received: from hagen (VTok2kZLge3X46kdpITlNEW1w736REvpcf445rz9DLwTouqmZlXs8j@[217.228.236.213]) by fmrl09.sul.t-online.com with esmtp id 1A5Nsk-02o3xQ0; Fri, 3 Oct 2003 13:13:58 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "'David Engberg'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 13:13:56 +0200
Organization: SyTrust
Message-ID: <000001c3899f$6feec430$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

> [...] An 
> environment called to task by a security auditor for sending 
> a canned response to a nonced request, the latter which by 
> technical definition is an assertion by a relying party that 
> the RP does NOT wish to receive a canned response, can very 
> easily send back any unsigned error.  

I want to comment two points here:

1) the "technical definition" you give in the sentence above: "[sending]
a nonced request [is by] technical definition [an] assertion by a
relying party [client] that the RP [client] does NOT wish to receive a
canned [pre-produced/cached] response".

I think the discussion here on the list shows that your "technical
definition" is not common ground here. It is NOT what I think and it is
NOT what RfC2560 states. There is another definition supported by
RfC2560 and some people here on the list: "A client sending a nonce
expresses its wish to get a nonced response."

>From my point of view this discussion showed:

A) your definition is not covered in RfC2560
B) there are multiple clients out there that make use of the benefits of
the definition as stated in RfC2560
C) there are multiple installations out there relying on these benefits

If you want to add such a change to the definition into the current
wording of RfC2560 one way or the other I think YOU are calling for
OCSPv2 - as this is a major change to some/many installations out there.

But I think thats the point where our discussion started :(

> [...] An 
> environment called to task by a security auditor for sending 
> a canned response to a nonced request, the latter which by 
> technical definition is an assertion by a relying party that 
> the RP does NOT wish to receive a canned response, can very 
> easily send back any unsigned error. It's best if we at least 
> standardize one for interoperability if nothing else.

2) I am not against an additional error message, as long as its use is
OPTIONAL for the responder and the current behaviour of the responders
(sending a non-nonced response back) is allowed, too. We can readily go
for a wording like this, if you need this error response urgently:

"If a responder cannot process a nonce he SHALL indicate this by sending
an error status "NonceNotAllowed" or by sending a response without
nonce."

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93203KP026360 for <[e-mail]>; Thu, 2 Oct 2003 19:00:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h932036H026359 for ietf-pkix-bks; Thu, 2 Oct 2003 19:00:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93202KP026353 for <[e-mail]>; Thu, 2 Oct 2003 19:00:02 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h931xtt04618; Thu, 2 Oct 2003 18:59:55 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "'David Engberg'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 19:03:18 -0700
Message-ID: <[e-mail]>
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)
In-Reply-To: <000001c3894c$31b681b0$4228a8c0@hagen>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: Florian Oelmaier
>
> . . .
>
> I am not a friend of adding an error message that
> adds nothing to the security of the protocol but
> introduces the need for a second round-trip
> into OCSPv1. As a client cannot really rely on the
> error message the situation will not get better.
> From a security point of view, the proposed error
> message does not bring any advantage (as it can be
> faked), technically it introduces the disadvantage of
> having to do two requests.
>
> *** I therefore suggest to leave OCSPv1 as it is
> (instead of making it worse) and work with Davids
> extension to go in for OCSPv2. ***


Florian,

As I've been trying to explain, the capability for
error-triggered nonce discovery is already in place.  An
environment called to task by a security auditor for sending a
canned response to a nonced request, the latter which by
technical definition is an assertion by a relying party that the
RP does NOT wish to receive a canned response, can very easily
send back any unsigned error.  It's best if we at least
standardize one for interoperability if nothing else.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h931ILKP024690 for <[e-mail]>; Thu, 2 Oct 2003 18:18:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h931ILKd024689 for ietf-pkix-bks; Thu, 2 Oct 2003 18:18:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h931IJKP024670 for <[e-mail]>; Thu, 2 Oct 2003 18:18:19 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd07.aul.t-online.de  by mailout10.sul.t-online.com with smtp  id 1A5EaB-0003sQ-01; Fri, 03 Oct 2003 03:18:11 +0200
Received: from hagen (EYMBDTZvoepZDIV+NhwDomOtKuFVKAxlqAOoJhHH9fyl37-VCcNRs6@[217.80.250.25]) by fmrl07.sul.t-online.com with esmtp id 1A5Ea5-1kQlge0; Fri, 3 Oct 2003 03:18:05 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "'David Engberg'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 03:18:03 +0200
Organization: SyTrust
Message-ID: <000001c3894c$31b681b0$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> The simple fix I most recently proposed could, I believe, be 
> applied to RFC 2560 as it progresses from Proposed to Draft 
> due to the poll's consensus.  Meanwhile, I strongly suspect 
> that the syntax and semantic changes of more sophisticated 
> solutions will force a version delta, a new I-D and all that 
> entails regarding WG, IETF and IESG ratification.  That is, OCSPv2.

I am not a friend of adding an error message that adds nothing to the
security of the protocol but introduces the need for a second round-trip
into OCSPv1. As a client cannot really rely on the error message the
situation will not get better. From a security point of view, the
proposed error message does not bring any advantage (as it can be
faked), technically it introduces the disadvantage of having to do two
requests.

*** I therefore suggest to leave OCSPv1 as it is (instead of making it
worse) and work with Davids extension to go in for OCSPv2. ***

In the meantime (until we get OCSPv2) people can use server-generated
nonces (which are compliant with the current state of RfC2560 and with
all existing clients out there). 

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92M5sKP016848 for <[e-mail]>; Thu, 2 Oct 2003 15:05:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92M5rrt016847 for ietf-pkix-bks; Thu, 2 Oct 2003 15:05:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92M5mKP016842 for <[e-mail]>; Thu, 2 Oct 2003 15:05:52 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h92M5Kt94833; Thu, 2 Oct 2003 15:05:20 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Frank Balluffi" <[e-mail]>, <[e-mail]>
Cc: "David Engberg" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 15:08:42 -0700
Message-ID: <[e-mail]>
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)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: Frank Balluffi
>
> . . .
>
> I too like the proposal to use a flag or an
> extension. Perhaps an extension could say the
> equivalent of, "This is a cached response."

Frank,

Would you object the v1/v2 dual paths as means of getting this
into place?

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92KmiKP013883 for <[e-mail]>; Thu, 2 Oct 2003 13:48:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92KmiBq013882 for ietf-pkix-bks; Thu, 2 Oct 2003 13:48:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imr6.us.db.com (imr6.us.db.com [160.83.65.199]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92KmhKP013877 for <[e-mail]>; Thu, 2 Oct 2003 13:48:43 -0700 (PDT) (envelope-from [e-mail])
Received: from sdbo1005.db.com by imr6.us.db.com  id h92Km5KK016366; Thu, 2 Oct 2003 16:48:06 -0400 (EDT)
Subject: RE: OCSP response pre-production
To: [e-mail]
Cc: "David Engberg" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Thu, 2 Oct 2003 16:48:36 -0400
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.12  |February 13, 2003) at 10/02/2003 04:48:39 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I too like the proposal to use a flag or an extension. Perhaps an extension could say the equivalent of, "This is a cached response."

Frank



                                                                                                                                       
                      "Terry Hayes"                                                                                                    
                      <thayes0993@aol.c        To:       "David Engberg" <[e-mail]>                                         
                      om>                      cc:       [e-mail]                                                             
                      Sent by:                 Subject:  RE: OCSP response pre-production                                              
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      10/02/2003 01:47                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       





I also like this proposal.  I believe that it is compatible with
existing responders that use pre-produced nonces, in the sense that
there aren't any changes required to allow them to continue operations.

Responders that only use pre-produced responses (with no nonce) would
benefit from changing their implement to add the extension.  This would
allow them to support the clients that implement dual-mode policy as
described in this thread.

As Florian has pointed out, this proposal is easier to understand than
having the server generate nonces.  In fact, I was going to write an
email that complained about overloading the nonce field to represent
this bit of information.  Given this proposal, I don't have to!

I also agree with Mike that we need to define an error that says that a
nonce is required for this responder.  This error is subject to
denial-of-service attacks (since it's unsigned), but we're already
exposed to that in this protocol anyway.

Terry

David Engberg wrote on 10/1/2003, 3:10 PM:

 > As an alternative, pre-generated responses could include a flag or
 > extension in their signed body to indicate that not only are they not
 > supplying a nonce with this response, but that they don't supply nonces
 > with any response, and if you trust that responder (via its public key
 > cert), then you may choose to accept the non-nonce-bearing response from
 > that server with this explicit flag (if that is your policy).
 >
 > This avoids the risk of someone replaying a response to you in which the
 > attacker chose not to supply a nonce, but you did.  It allows a client
 > to distinguish between a server saying "Here's a response without a
 > nonce because you I think you didn't ask for one" and "Here's a response
 > without a nonce because the responder for you or your CA does not use
 > nonces."
 >
 > I believe the following is a valid security policy which some (most?)
 > clients may choose to implement as an option:
 >
 >    - Send a nonce with every request
 >    - Accept a response with a matching nonce from any trusted responder
 >    - Accept a response with a nonceUnsupported extension from any
 >        trusted responder
 >    - Reject a response with no nonce and no nonceUnsupported extension
 >
 > This would allow the client to be much more usable with random public
 > certs (using AIA fields and delegated responder certs) in real-world
 > settings like secure email, etc.
 >







--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92JNWKP011305 for <[e-mail]>; Thu, 2 Oct 2003 12:23:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92JNW55011304 for ietf-pkix-bks; Thu, 2 Oct 2003 12:23:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92JNTKP011293 for <[e-mail]>; Thu, 2 Oct 2003 12:23:30 -0700 (PDT) (envelope-from [e-mail])
Received: from corestreet.com (engberg.corestreet.com [192.168.2.87]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id h92JNIxh026076; Thu, 2 Oct 2003 15:23:18 -0400
Message-ID: <[e-mail]>
Date: Thu, 02 Oct 2003 15:22:31 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet, Ltd.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP response pre-production
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If adding a new top-level error code is possible in v1, and adding a new 
response extension to indicate nonceUnsupported (or similar solution) is 
only possible in v2, then this may be the best course of action.

Thanks,
Dave


Michael Myers wrote:
> Dave,
> 
> Even if we do nothing, means currently exist for clients to
> discover if a server respects nonces via error signalling.  A
> non-nonced response to a nonced request itself being an error in
> perhaps then 11 of 12 client side implementions, including your
> own.
> 
> All along I've been trying to avoid opening the pandora's box of
> OCSPv2, but I guess it's time to do so.
> 
> The simple fix I most recently proposed could, I believe, be
> applied to RFC 2560 as it progresses from Proposed to Draft due
> to the poll's consensus.  Meanwhile, I strongly suspect that the
> syntax and semantic changes of more sophisticated solutions will
> force a version delta, a new I-D and all that entails regarding
> WG, IETF and IESG ratification.  That is, OCSPv2.
> 
> We have a narrow window of opportunity to fix v1 as proposed and
> so stem the tide of unilateral approaches to resolving its
> current ambiguity regarding the use of nonces.  This way,
> everybody's at least on the same page in the near term.
> 
> I propose we do so and in parallel move on to v2.  The v2
> discussions will predictably lead us into latent issues not
> associated with nonces.  As these things go, that will take a
> while.
> 
> Do you agree to this course of action?
> 
> Mike
> 
> 
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92Ie2KP009671 for <[e-mail]>; Thu, 2 Oct 2003 11:40:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92Ie2pS009670 for ietf-pkix-bks; Thu, 2 Oct 2003 11:40:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92Ie1KP009664 for <[e-mail]>; Thu, 2 Oct 2003 11:40:01 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h92Idwt85708; Thu, 2 Oct 2003 11:39:58 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Terry Hayes" <[e-mail]>, "David Engberg" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 11:43:22 -0700
Message-ID: <[e-mail]>
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)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From:  Terry Hayes
>
> . . .
>
> I also agree with Mike that we need to define an
> error that says that a nonce is required for this
> responder.  This error is subject to
> denial-of-service attacks (since it's unsigned),
> but we're already exposed to that in this protocol
> anyway.

Actually, Terry, errors were left unsigned largely to enable
edge servers to respond more effectively to a DOS flood than
might an interior signing server.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92IVHKP009200 for <[e-mail]>; Thu, 2 Oct 2003 11:31:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92IVHlT009199 for ietf-pkix-bks; Thu, 2 Oct 2003 11:31:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92IVEKP009194 for <[e-mail]>; Thu, 2 Oct 2003 11:31:16 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h92IVDt85343; Thu, 2 Oct 2003 11:31:13 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 11:34:37 -0700
Message-ID: <[e-mail]>
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)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

Even if we do nothing, means currently exist for clients to
discover if a server respects nonces via error signalling.  A
non-nonced response to a nonced request itself being an error in
perhaps then 11 of 12 client side implementions, including your
own.

All along I've been trying to avoid opening the pandora's box of
OCSPv2, but I guess it's time to do so.

The simple fix I most recently proposed could, I believe, be
applied to RFC 2560 as it progresses from Proposed to Draft due
to the poll's consensus.  Meanwhile, I strongly suspect that the
syntax and semantic changes of more sophisticated solutions will
force a version delta, a new I-D and all that entails regarding
WG, IETF and IESG ratification.  That is, OCSPv2.

We have a narrow window of opportunity to fix v1 as proposed and
so stem the tide of unilateral approaches to resolving its
current ambiguity regarding the use of nonces.  This way,
everybody's at least on the same page in the near term.

I propose we do so and in parallel move on to v2.  The v2
discussions will predictably lead us into latent issues not
associated with nonces.  As these things go, that will take a
while.

Do you agree to this course of action?

Mike






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92HlcKP006771 for <[e-mail]>; Thu, 2 Oct 2003 10:47:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92HlcjS006770 for ietf-pkix-bks; Thu, 2 Oct 2003 10:47:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-m03.mx.aol.com (imo-m03.mx.aol.com [64.12.136.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92HlaKP006763 for <[e-mail]>; Thu, 2 Oct 2003 10:47:37 -0700 (PDT) (envelope-from [e-mail])
Received: from [e-mail] by imo-m03.mx.aol.com (mail_out_v36_r1.1.) id z.141.1a10d10a (16086); Thu, 2 Oct 2003 13:47:25 -0400 (EDT)
Received: from  pc655301.nscp.aoltw.net (h-10-169-25-113.nscp.aoltw.net [10.169.25.113]) by air-id10.mx.aol.com (v96.8) with ESMTP id MAILINID103-3ed63f7c64ac17e; Thu, 02 Oct 2003 13:47:25 -0400
Date: Thu, 2 Oct 2003 10:47:30 -0700
From: "Terry Hayes" <[e-mail]>
Subject: RE: OCSP response pre-production
To: "David Engberg" <[e-mail]>
cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References:  <[e-mail]>
X-Mailer: AOL Communicator (20030917.2 Win)
Organization: AOL
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.25.113
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I also like this proposal.  I believe that it is compatible with 
existing responders that use pre-produced nonces, in the sense that 
there aren't any changes required to allow them to continue operations.

Responders that only use pre-produced responses (with no nonce) would 
benefit from changing their implement to add the extension.  This would 
allow them to support the clients that implement dual-mode policy as 
described in this thread.

As Florian has pointed out, this proposal is easier to understand than 
having the server generate nonces.  In fact, I was going to write an 
email that complained about overloading the nonce field to represent 
this bit of information.  Given this proposal, I don't have to!

I also agree with Mike that we need to define an error that says that a 
nonce is required for this responder.  This error is subject to 
denial-of-service attacks (since it's unsigned), but we're already 
exposed to that in this protocol anyway.

Terry

David Engberg wrote on 10/1/2003, 3:10 PM:

 > As an alternative, pre-generated responses could include a flag or
 > extension in their signed body to indicate that not only are they not
 > supplying a nonce with this response, but that they don't supply nonces
 > with any response, and if you trust that responder (via its public key
 > cert), then you may choose to accept the non-nonce-bearing response from
 > that server with this explicit flag (if that is your policy).
 >
 > This avoids the risk of someone replaying a response to you in which the
 > attacker chose not to supply a nonce, but you did.  It allows a client
 > to distinguish between a server saying "Here's a response without a
 > nonce because you I think you didn't ask for one" and "Here's a response
 > without a nonce because the responder for you or your CA does not use
 > nonces."
 >
 > I believe the following is a valid security policy which some (most?)
 > clients may choose to implement as an option:
 >
 >    - Send a nonce with every request
 >    - Accept a response with a matching nonce from any trusted responder
 >    - Accept a response with a nonceUnsupported extension from any
 >        trusted responder
 >    - Reject a response with no nonce and no nonceUnsupported extension
 >
 > This would allow the client to be much more usable with random public
 > certs (using AIA fields and delegated responder certs) in real-world
 > settings like secure email, etc.
 >




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92H3XKP004181 for <[e-mail]>; Thu, 2 Oct 2003 10:03:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92H3Xf8004180 for ietf-pkix-bks; Thu, 2 Oct 2003 10:03:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92H3WKP004169 for <[e-mail]>; Thu, 2 Oct 2003 10:03:32 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h92H3St80803; Thu, 2 Oct 2003 10:03:28 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 10:06:52 -0700
Message-ID: <[e-mail]>
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)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

I used the pop-up as an example.  It could very well be a
one-time configuration issue.   Or, as Jean-Marc Desperrier
suggested, all this hoo-hah could be a moot point when reduced
to practice.  In any case, specific software design features are
out of scope.

As you point out, caching servers today send back a non-nonced
response to a nonced request because 2560 is regrettably silent
on the point. 10 of 12 implementors seem to have understood the
principles of nonce use anyhow.  If that isn't rough consensus
and running code, I don't know what is.  Despite that, if this
WG, its chairs and our AD wish to condone the practice of
ignoring a nonce, I'd be happy to abide by that decision.

Mike



> -----Original Message-----
> From: David Engberg [mailto:[e-mail]]
> Sent: Thursday, October 02, 2003 9:41 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: OCSP response pre-production
>
>
>
> If the only change is an error code in the unsigned
> portion of the
> protocol, there is no way for a client to
> automatically tell that the
> responder is intentionally configured to never send nonces.
>
> This prevents a client from choosing this
> automatically-enforced
> security policy:
>
>    Require nonce from servers that support nonces.
>    Accept responses without nonces from trusted
> responders that
>       securely indicate they won't ever provide a nonce.
>
> Like you said, a solution based only around an
> unsigned error code would
> require explicit user acceptance for each responder,
> while the most
> users don't have the faintest idea what nonces (or
> OCSP for that matter)
> are.  The pop-up example you listed may as well be in
> Latin for the
> majority of users.
>
> If nothing changes in the spec, caching-only servers
> will continue to
> send back a response without a nonce.  They won't
> send back any error
> because this is not an error under the current RFC.
>
>
> Michael Myers wrote:
> >
> >
> > If we don't define a nonce-specific error, it's
> predictable that
> > client developers will choose one of the existing 5 unsigned
> > error values in order to pop up a dialog that says,
> essentially,
> > "You used a nonce and received an error.  If you want to try
> > again not using nonces, click here."
> >
> > It doesn't matter much which error; any one will do
> in order to
> > discover if nonce use is the problem.  In fact if nothing
> > changed I'm wondering what the server side *would*
> send back?
> > I've recently seen suggestions on this list for
> > malFormedRequest, internalError and unauthorized.
> >
> > Not defining a nonce-specific error value escapes nothing.
> > Clients can today enable relying parties to achieve their
> > intended goals via error-triggered nonce capability
> discovery.
> >
> > Mike
> >
> >
> >
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92Gg7KP003454 for <[e-mail]>; Thu, 2 Oct 2003 09:42:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92Gg7P2003453 for ietf-pkix-bks; Thu, 2 Oct 2003 09:42:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92Gg6KP003439 for <[e-mail]>; Thu, 2 Oct 2003 09:42:07 -0700 (PDT) (envelope-from [e-mail])
Received: from corestreet.com (engberg.corestreet.com [192.168.2.87]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id h92Gfrxh024493; Thu, 2 Oct 2003 12:41:53 -0400
Message-ID: <[e-mail]>
Date: Thu, 02 Oct 2003 12:41:06 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet, Ltd.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP response pre-production
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If the only change is an error code in the unsigned portion of the 
protocol, there is no way for a client to automatically tell that the 
responder is intentionally configured to never send nonces.

This prevents a client from choosing this automatically-enforced 
security policy:

   Require nonce from servers that support nonces.
   Accept responses without nonces from trusted responders that
      securely indicate they won't ever provide a nonce.

Like you said, a solution based only around an unsigned error code would 
require explicit user acceptance for each responder, while the most 
users don't have the faintest idea what nonces (or OCSP for that matter) 
are.  The pop-up example you listed may as well be in Latin for the 
majority of users.

If nothing changes in the spec, caching-only servers will continue to 
send back a response without a nonce.  They won't send back any error 
because this is not an error under the current RFC.


Michael Myers wrote:
> 
> 
> If we don't define a nonce-specific error, it's predictable that
> client developers will choose one of the existing 5 unsigned
> error values in order to pop up a dialog that says, essentially,
> "You used a nonce and received an error.  If you want to try
> again not using nonces, click here."
> 
> It doesn't matter much which error; any one will do in order to
> discover if nonce use is the problem.  In fact if nothing
> changed I'm wondering what the server side *would* send back?
> I've recently seen suggestions on this list for
> malFormedRequest, internalError and unauthorized.
> 
> Not defining a nonce-specific error value escapes nothing.
> Clients can today enable relying parties to achieve their
> intended goals via error-triggered nonce capability discovery.
> 
> Mike
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92GSoKP003051 for <[e-mail]>; Thu, 2 Oct 2003 09:28:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92GSo8f003050 for ietf-pkix-bks; Thu, 2 Oct 2003 09:28:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.aauckland.ac.nz [130.216.33.151] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92GSgKP003040 for <[e-mail]>; Thu, 2 Oct 2003 09:28:49 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h92GSc4W022842; Fri, 3 Oct 2003 04:28:38 +1200
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h92GU4Q23093; Fri, 3 Oct 2003 04:30:04 +1200
Date: Fri, 3 Oct 2003 04:30:04 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: OCSP response pre-production
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Michael Myers" <[e-mail]> writes:

>If we don't define a nonce-specific error, it's predictable that client
>developers will choose one of the existing 5 unsigned error values in order
>to pop up a dialog that says, essentially, "You used a nonce and received an
>error.  If you want to try again not using nonces, click here."

.... which the user will mentally translate to "Quadrant change in relocatable
expression in subspace $CODE$" (yes, that's a real error message from HP-UX)
which after another level of mental translation becomes "Go boom fall down.
Click here make better".  After clicking OK, everything works again (or at
least something happens, either a cached response or a replay attack, but in
any case the annoying warning goes away so everything's all right).

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92G1TKP001887 for <[e-mail]>; Thu, 2 Oct 2003 09:01:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92G1Tvm001886 for ietf-pkix-bks; Thu, 2 Oct 2003 09:01:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92G1SKP001879 for <[e-mail]>; Thu, 2 Oct 2003 09:01:28 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Oct 2003 11:02:30 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 11:00:22 -0500
Message-ID: <000401c388fe$4d3b2ba0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 02 Oct 2003 16:02:30.0921 (UTC) FILETIME=[9595F790:01C388FE]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with this too, the support for nonces should indicated in the
signed content, either as a special flag or as Julien suggested using
the nextUpdate field. I prefer any of these options over the definition
of a new (unsigned) error message.

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Julien Stern
> Sent: Thursday, October 02, 2003 8:41 AM
> To: [e-mail]
> Subject: Re: OCSP response pre-production
> 
> 
> I fully agree with this too. The server has to indicate whether it
> supports nonces or not INSIDE the signed content. Server generated
> nonces are a way, this extension is another (hmm, well, the equivalent
> of server generated nonces would be an ICanProvideANonceIfYouWish
> extension, but ...).
> On this other hand, I think that it is dangerous to indicate this fact
> as an _unsigned_ error, as this error reply could easily be faked by
an
> attacker, making him think a server does not support nonces while in
> fact it does.
> 
> --
> Julien




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92FkfKP001338 for <[e-mail]>; Thu, 2 Oct 2003 08:46:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92Fkf8D001337 for ietf-pkix-bks; Thu, 2 Oct 2003 08:46:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92FkeKP001332 for <[e-mail]>; Thu, 2 Oct 2003 08:46:40 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h92Fkft77150 for <[e-mail]>; Thu, 2 Oct 2003 08:46:41 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 08:50:05 -0700
Message-ID: <[e-mail]>
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)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If we don't define a nonce-specific error, it's predictable that
client developers will choose one of the existing 5 unsigned
error values in order to pop up a dialog that says, essentially,
"You used a nonce and received an error.  If you want to try
again not using nonces, click here."

It doesn't matter much which error; any one will do in order to
discover if nonce use is the problem.  In fact if nothing
changed I'm wondering what the server side *would* send back?
I've recently seen suggestions on this list for
malFormedRequest, internalError and unauthorized.

Not defining a nonce-specific error value escapes nothing.
Clients can today enable relying parties to achieve their
intended goals via error-triggered nonce capability discovery.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92Ep4KP098912 for <[e-mail]>; Thu, 2 Oct 2003 07:51:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92Ep4WR098910 for ietf-pkix-bks; Thu, 2 Oct 2003 07:51:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92Ep2KP098905 for <[e-mail]>; Thu, 2 Oct 2003 07:51:03 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23250; Thu, 2 Oct 2003 10:50:53 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt
Date: Thu, 02 Oct 2003 10:50:53 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure:       
                          Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow et al.
	Filename	: draft-ietf-pkix-certpathbuild-01.txt
	Pages		: 67
	Date		: 2003-10-2
	
This document was written to provide guidance and recommendations to 
developers building X.509 public-key certification paths within their 
applications.  By following the guidance and recommendations defined 
in this document, an application developer is more likely to develop 
a robust X.509 certificate enabled application that can build valid 
certification paths across a wide range of PKI environments.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-certpathbuild-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-certpathbuild-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-certpathbuild-01.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92ECnKP097729 for <[e-mail]>; Thu, 2 Oct 2003 07:12:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92ECnVL097728 for ietf-pkix-bks; Thu, 2 Oct 2003 07:12:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92ECmKP097721 for <[e-mail]>; Thu, 2 Oct 2003 07:12:48 -0700 (PDT) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id h92ECe4c001409; Thu, 2 Oct 2003 07:12:40 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 07:15:41 -0700
Message-ID: <[e-mail]>
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: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree.

A

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Jean-Marc Desperrier
> Sent: Thursday, October 02, 2003 2:19 AM
> To: [e-mail]
> Subject: Re: OCSP response pre-production
> 
> 
> 
> David Engberg wrote:
> > I would prefer a signalling mechanism that does not require two 
> > round-trip communications to establish nonce support, 
> 
> May I say we should *NOT* aim to fullfill this ?
> 
> If we don't, everything is easy.
> 
> Clients that requires freshest response send a nonce, and get back an 
> error if it's not possible to give freshest response.
> Client that don't require it, send no nonce.
> 
> Client that would like it, but don't require it, make a round trip, and 
> cache the fact the server can't supply freshest response, so they do the 
> round trip only once.
> 
> My opinion is :
> - in real life implementations, it's not so common to both trust an OCSP 
> responder, and not know in advance if it can supply fresh responses or 
> not. Even if it's the case, there won't be so many different OCSP 
> responders, and it won't take long to discover they don't provide fresh 
> answers.
> 
> - The global security brought by trying to get a fresh response, but 
> being ready to accept a non-fresh one, can hardly be said to be any 
> different from directly accepting a non-fresh one. If the system was 
> audited, I'm doubtful auditors would think it brings any real difference.
> 
> So I don't see a reason to go such lengths to support this.
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92DehKP095797 for <[e-mail]>; Thu, 2 Oct 2003 06:40:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92Deheg095796 for ietf-pkix-bks; Thu, 2 Oct 2003 06:40:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92DefKP095791 for <[e-mail]>; Thu, 2 Oct 2003 06:40:42 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 42D7262DB9 for <[e-mail]>; Thu,  2 Oct 2003 15:40:38 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 035504305 for <[e-mail]>; Thu,  2 Oct 2003 15:40:39 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 09156-07 for <[e-mail]>; Thu,  2 Oct 2003 15:40:38 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id C7027409E for <[e-mail]>; Thu,  2 Oct 2003 15:40:38 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Thu,  2 Oct 2003 15:40:38 +0200
From: "Julien Stern" <[e-mail]>
Date: Thu, 2 Oct 2003 15:40:38 +0200
To: [e-mail]
Subject: Re: OCSP response pre-production
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Oct 02, 2003 at 08:45:39AM -0000, Florian Oelmaier wrote:
> 
> > As an alternative, pre-generated responses could include a flag or 
> > extension in their signed body to indicate that not only are they not 
> > supplying a nonce with this response, but that they don't supply nonces 
> > with any response, and if you trust that responder (via its public key 
> > cert), then you may choose to accept the non-nonce-bearing response from 
> > that server with this explicit flag (if that is your policy).
> > 
> > This avoids the risk of someone replaying a response to you in which the 
> > attacker chose not to supply a nonce, but you did.  It allows a client 
> > to distinguish between a server saying "Here's a response without a 
> > nonce because you I think you didn't ask for one" and "Here's a response 
> > without a nonce because the responder for you or your CA does not use 
> > nonces."
> > 
> > I believe the following is a valid security policy which some (most?) 
> > clients may choose to implement as an option:
> > 
> >    - Send a nonce with every request
> >    - Accept a response with a matching nonce from any trusted responder
> >    - Accept a response with a nonceUnsupported extension from any
> >        trusted responder
> >    - Reject a response with no nonce and no nonceUnsupported extension
> > 
> > This would allow the client to be much more usable with random public 
> > certs (using AIA fields and delegated responder certs) in real-world 
> > settings like secure email, etc.
> > 
> 
> I fully agree with this. It seems to be a good idea.
> 
> My idea of server-generated nonces is simply the other way round: If the responder wants to signal "nonceUnsupported", the response does not include a nonce, if the responder generally supports nonces it simply generates one for requests not containing one.
> 
> From my point of view both proposals do technically the same and are fine for me. Davids "nonceUnsupported"-extension is easier to understand and more clear while server generated nonces do not need changes in clients like Juliens or mine. I am fine with both - tell me when to begin implementing.

I fully agree with this too. The server has to indicate whether it
supports nonces or not INSIDE the signed content. Server generated
nonces are a way, this extension is another (hmm, well, the equivalent
of server generated nonces would be an ICanProvideANonceIfYouWish
extension, but ...).
On this other hand, I think that it is dangerous to indicate this fact
as an _unsigned_ error, as this error reply could easily be faked by an
attacker, making him think a server does not support nonces while in
fact it does.

--
Julien


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92CErKP092095 for <[e-mail]>; Thu, 2 Oct 2003 05:14:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92CEr3f092094 for ietf-pkix-bks; Thu, 2 Oct 2003 05:14:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92CEqKP092085 for <[e-mail]>; Thu, 2 Oct 2003 05:14:52 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (sccrmhc11) with ESMTP id <20031002121447011006slfpe>; Thu, 2 Oct 2003 12:14:47 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1A52Os-0008Qd-00; Thu, 02 Oct 2003 08:17:42 -0400
Message-ID: <[e-mail]>
Date: Thu, 02 Oct 2003 08:17:41 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jean-Marc Desperrier <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP response pre-production
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jean-Marc Desperrier wrote:
> Clients that requires freshest response send a nonce, and get back an 
> error if it's not possible to give freshest response.
> Client that don't require it, send no nonce.
 >
> Client that would like it, but don't require it, make a round trip, and 
> cache the fact the server can't supply freshest response, so they do the 
> round trip only once.

I could live with a two-trip solution as an alternative as long as the 
error is contained in a signed message which can be pre-generated for 
that responder.  If the error is in the unsigned portion of the 
protocol, a client can't really tell a nonceUnsupported server from an 
attacker on the network, which means its only realistic option is to 
reject the response and quit.

An extra round-trip communication is unfortunate, but not a show-stopper 
if it conveys some other fundamental advantage that I'm missing.



> - in real life implementations, it's not so common to both trust an OCSP 
> responder, and not know in advance if it can supply fresh responses or 
> not. Even if it's the case, there won't be so many different OCSP 
> responders, and it won't take long to discover they don't provide fresh 
> answers.

You may be only thinking of closed internal PKIs with one or two CAs and 
hard-coded clients.  I'm thinking of the broader case where I may want 
to accept signed emails from everyone that chains or bridges to one of 
my trusted roots.  I may accept signed emails from employees of Acme 
Novelties because their CA chains to a Verisign root, and their AIA OCSP 
responder was properly delegated by their CA (OCSP Signing).  I 
certainly have no idea whether Acme's responder keys are online 
(nonce-supporting) or off (nonceUnsupported) before my first request, 
even though I'm prepared to accept whichever security policy the CA chooses.

I think it is a valid and secure _option_ for a client to say "accept 
the revocation security policies chosen by trusted CAs and/or 
responders."  If a CA only publishes CRLs every 24 hours, its OCSP 
infrastructure should be able to signal to interested clients that they 
shouldn't waste everyone's time and CPU cycles by sending nonces just to 
get "fresh" views of the same cached CRL.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h92BhuKP090756 for <[e-mail]>; Thu, 2 Oct 2003 04:43:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h92Bht8f090755 for ietf-pkix-bks; Thu, 2 Oct 2003 04:43:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h92BhrKP090749 for <[e-mail]>; Thu, 2 Oct 2003 04:43:54 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 4129 invoked by uid 1649); 2 Oct 2003 11:43:54 -0000
Date: 2 Oct 2003 11:43:54 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: Jean-Marc Desperrier <[e-mail]>, [e-mail]
Subject: Re: OCSP response pre-production
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> David Engberg wrote:
> > I would prefer a signalling mechanism that does not require two 
> > round-trip communications to establish nonce support, 
> 
> May I say we should *NOT* aim to fullfill this ?

Seeing that it is rather easy to do it (as shown in both proposals), I would vote for fullfilling this requirement.

> My opinion is :
> - in real life implementations, it's not so common to both trust an OCSP 
> responder, and not know in advance if it can supply fresh responses or 
> not. 

A lot of clients use AIA to find the OCSP-URL and use the OCSP-signing certificate extension to trust the OCSP Responder. The case of contacting an "unknown" OCSP-Responder will even become more important the more PKIs we find our there.

> - The global security brought by trying to get a fresh response, but 
> being ready to accept a non-fresh one, can hardly be said to be any 
> different from directly accepting a non-fresh one. If the system was 
> audited, I'm doubtful auditors would think it brings any real difference.

With our proposals this depends on the responder. If your responder supports nonces, the described client WILL use it. If your responder does not, the client will not. The client will NOT accept a nonce-less response from a responder being able to support nonces. 

Thus an auditor will see a real difference regarding certificates from some CAs - as for certain CAs a client will not accept nonce-less OCSP responses. This is a very common thing for every auditor out there: having CAs with different trust levels.

Additionally when an OCSP client (for example an SCVP server) detects multiple paths for a given certificate, the "freshness" of a validation may be used in a policy to establish a certain "trust level".

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h929JBKP085091 for <[e-mail]>; Thu, 2 Oct 2003 02:19:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h929JBcg085090 for ietf-pkix-bks; Thu, 2 Oct 2003 02:19:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h929J9KP085082 for <[e-mail]>; Thu, 2 Oct 2003 02:19:09 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft4.fr.colt.net with ESMTP id h929J4m31340 for <[e-mail]>; Thu, 2 Oct 2003 11:19:04 +0200
Message-ID: <[e-mail]>
Date: Thu, 02 Oct 2003 11:19:04 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030811
X-Accept-Language: en, fr, en-us, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP response pre-production
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Engberg wrote:
> I would prefer a signalling mechanism that does not require two 
> round-trip communications to establish nonce support, 

May I say we should *NOT* aim to fullfill this ?

If we don't, everything is easy.

Clients that requires freshest response send a nonce, and get back an 
error if it's not possible to give freshest response.
Client that don't require it, send no nonce.

Client that would like it, but don't require it, make a round trip, and 
cache the fact the server can't supply freshest response, so they do the 
round trip only once.

My opinion is :
- in real life implementations, it's not so common to both trust an OCSP 
responder, and not know in advance if it can supply fresh responses or 
not. Even if it's the case, there won't be so many different OCSP 
responders, and it won't take long to discover they don't provide fresh 
answers.

- The global security brought by trying to get a fresh response, but 
being ready to accept a non-fresh one, can hardly be said to be any 
different from directly accepting a non-fresh one. If the system was 
audited, I'm doubtful auditors would think it brings any real difference.

So I don't see a reason to go such lengths to support this.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h928jkKP083946 for <[e-mail]>; Thu, 2 Oct 2003 01:45:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h928jkDh083945 for ietf-pkix-bks; Thu, 2 Oct 2003 01:45:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h928jiKP083939 for <[e-mail]>; Thu, 2 Oct 2003 01:45:45 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 2863 invoked by uid 1649); 2 Oct 2003 08:45:39 -0000
Date: 2 Oct 2003 08:45:39 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: David Engberg <[e-mail]>, [e-mail]
Subject: RE: OCSP response pre-production
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> As an alternative, pre-generated responses could include a flag or 
> extension in their signed body to indicate that not only are they not 
> supplying a nonce with this response, but that they don't supply nonces 
> with any response, and if you trust that responder (via its public key 
> cert), then you may choose to accept the non-nonce-bearing response from 
> that server with this explicit flag (if that is your policy).
> 
> This avoids the risk of someone replaying a response to you in which the 
> attacker chose not to supply a nonce, but you did.  It allows a client 
> to distinguish between a server saying "Here's a response without a 
> nonce because you I think you didn't ask for one" and "Here's a response 
> without a nonce because the responder for you or your CA does not use 
> nonces."
> 
> I believe the following is a valid security policy which some (most?) 
> clients may choose to implement as an option:
> 
>    - Send a nonce with every request
>    - Accept a response with a matching nonce from any trusted responder
>    - Accept a response with a nonceUnsupported extension from any
>        trusted responder
>    - Reject a response with no nonce and no nonceUnsupported extension
> 
> This would allow the client to be much more usable with random public 
> certs (using AIA fields and delegated responder certs) in real-world 
> settings like secure email, etc.
> 

I fully agree with this. It seems to be a good idea.

My idea of server-generated nonces is simply the other way round: If the responder wants to signal "nonceUnsupported", the response does not include a nonce, if the responder generally supports nonces it simply generates one for requests not containing one.

>From my point of view both proposals do technically the same and are fine for me. Davids "nonceUnsupported"-extension is easier to understand and more clear while server generated nonces do not need changes in clients like Juliens or mine. I am fine with both - tell me when to begin implementing.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91MfDKP005941 for <[e-mail]>; Wed, 1 Oct 2003 15:41:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91MfDAv005940 for ietf-pkix-bks; Wed, 1 Oct 2003 15:41:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91MfBKP005926 for <[e-mail]>; Wed, 1 Oct 2003 15:41:11 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd05.aul.t-online.de  by mailout09.sul.t-online.com with smtp  id 1A4peg-0006wo-01; Thu, 02 Oct 2003 00:41:10 +0200
Received: from hagen (Gz8XoYZGge0sjG-RlpFCGvum9-FlcgMRfdqIsIcp3+T0Eu5kD1smZU@[217.80.248.249]) by fmrl05.sul.t-online.com with esmtp id 1A4pef-0ItyRU0; Thu, 2 Oct 2003 00:41:09 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SUMMARY of  nonces in OCSP
Date: Thu, 2 Oct 2003 00:41:07 +0200
Organization: SyTrust
Message-ID: <000001c3886d$1ae84bb0$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

can you please explain to me why we need 3 and 4? Both requirements seem
to be fulfilled rather fine in the current state of RfC2560: the
responder simply sends back a response without nonce. What is the
problem with the current solution to this problem?

-- 
Florian Oelmaier
SyTrust

PS: While our software is not broken by the proposed language due to
good configurability, I cannot guarantee for all installations.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Michael Myers
> Sent: Wednesday, October 01, 2003 7:20 PM
> To: [e-mail]
> Subject: SUMMARY of nonces in OCSP
> 
> 
> 
> All,
> 
> Towards consensus on a path forward, here's where we are with 
> the poll and recent discussions:
> 
> 1.  Nonces break caching.  No news there.
> 
> 2.  Of the eleven responding implementors to the poll 
> regarding normative language in 2560 on the use of nonces, 
> nine are not broken by the proposed language while two rely 
> on a caching.
> 
> 3.  We need to define an error value specific to a 
> responder's inability to accept a nonce.
> 
> 4.  Closely related to #3, we need some means of signalling 
> between a requestor and a responder in order for the 
> requestor to determine if use of a nonce would be accepted.
> 
> Anyone disagree?
> 
> Below is the specific list of respondents to poll.  Did I 
> miss anybody?
> 
> 
> NOT BROKEN
> ----------
> Marius Marian, Politenico di Torino
> Ryan Hurst, Microsoft
> Yasir Khan, Ascertia
> Miguel Rodriguez, SeguriDATA
> Peter Gutman, (doing what Peter does)
> Eric Wertz, RSA
> Florian Oelmaier, SyTrust
> Terry Hayes, Netscape
> Stephen Henson, OpenSSL
> 
> 
> BROKEN DUE TO CACHING
> ---------------------
> Alex Deacon, VeriSign
> David Engberg, CoreStreet
> 
> 
> Mike
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91MBPKP004582 for <[e-mail]>; Wed, 1 Oct 2003 15:11:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91MBPAG004581 for ietf-pkix-bks; Wed, 1 Oct 2003 15:11:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91MBMKP004569 for <[e-mail]>; Wed, 1 Oct 2003 15:11:23 -0700 (PDT) (envelope-from [e-mail])
Received: from corestreet.com (engberg.corestreet.com [192.168.2.87]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id h91MBIxh015703 for <[e-mail]>; Wed, 1 Oct 2003 18:11:19 -0400
Message-ID: <[e-mail]>
Date: Wed, 01 Oct 2003 18:10:33 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet, Ltd.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: RE: OCSP response pre-production
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with the general idea of having an unambiguous way for a 
responder to indicate that it will not provide nonces in responses.  I 
think it may be unnecessarily restrictive to say that every client must 
automatically reject a response without a nonce, but that would not 
directly impact our software either way.

I would prefer a signalling mechanism that does not require two 
round-trip communications to establish nonce support, and that does not 
add any significant size to the body of pre-generated responses to 
indicate that they don't have nonces in them (which is evident).

Michael's initial proposal (below) could work, but has the two issues of 
requiring two round-trips for negotiation and returning the 
"unsupported" message in the unsigned portion of the body rather than in 
the signed body.  I also would prefer to remove the last sentence of the 
semantics or at least tone it down as unnecessarily focused on one 
hypothetical risk above all others (e.g. remote server key compromise).

 > SYNTAX:     Expand v1 OCSPResponseStatus syntax to
 >             include (7) noncesNotAccepted.
 >
 >
 > SEMANTICS:  Responders SHOULD respond back with the
 >             requestor's nonce but if can't then SHALL
 >             respond with an error message of the value
 >             noncesNotAccepted.
 >
 >             Requestors SHALL reject signed responses
 >             that fail to incorporate a supplied nonce.
 >
 >             Upon receipt of noncesNotRequired, requestors
 >             MAY retry the request without using a nonce.
 >             Requestors are STRONGLY ADVISED that doing
 >             so MAY subject them to additional risk.

As an alternative, pre-generated responses could include a flag or 
extension in their signed body to indicate that not only are they not 
supplying a nonce with this response, but that they don't supply nonces 
with any response, and if you trust that responder (via its public key 
cert), then you may choose to accept the non-nonce-bearing response from 
that server with this explicit flag (if that is your policy).

This avoids the risk of someone replaying a response to you in which the 
attacker chose not to supply a nonce, but you did.  It allows a client 
to distinguish between a server saying "Here's a response without a 
nonce because you I think you didn't ask for one" and "Here's a response 
without a nonce because the responder for you or your CA does not use 
nonces."

I believe the following is a valid security policy which some (most?) 
clients may choose to implement as an option:

   - Send a nonce with every request
   - Accept a response with a matching nonce from any trusted responder
   - Accept a response with a nonceUnsupported extension from any
       trusted responder
   - Reject a response with no nonce and no nonceUnsupported extension

This would allow the client to be much more usable with random public 
certs (using AIA fields and delegated responder certs) in real-world 
settings like secure email, etc.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91LlDKP003771 for <[e-mail]>; Wed, 1 Oct 2003 14:47:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91LlDBw003770 for ietf-pkix-bks; Wed, 1 Oct 2003 14:47:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91LlCKP003764 for <[e-mail]>; Wed, 1 Oct 2003 14:47:12 -0700 (PDT) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 1 Oct 2003 14:47:12 -0700
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Wed, 1 Oct 2003 14:47:09 -0700
Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Oct 2003 14:47:08 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 14:47:08 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 14:47:08 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 1 Oct 2003 14:47:08 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SUMMARY of  nonces in OCSP
Date: Wed, 1 Oct 2003 14:47:00 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SUMMARY of  nonces in OCSP
thread-index: AcOIUxd46xR/qml8RRKclvwrZDkDYAAEl5QA
From: "Ryan M. Hurst" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 01 Oct 2003 21:47:08.0065 (UTC) FILETIME=[8FB60110:01C38865]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h91LlCKP003766
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In-line

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Michael Myers
Sent: Wednesday, October 01, 2003 10:20 AM
To: [e-mail]
Subject: SUMMARY of nonces in OCSP


All,

Towards consensus on a path forward, here's where we are with the poll
and recent discussions:

1.  Nonces break caching.  No news there.
[rmh] Yup.

2.  Of the eleven responding implementors to the poll regarding
normative language in 2560 on the use of nonces, nine are not broken by
the proposed language while two rely on a caching.
[rmh] Yup.

3.  We need to define an error value specific to a responder's inability
to accept a nonce.
[rmh] not sure we need this, I am OK with internalError, notAuthorized
or a new error but preferably I as a client want a response because I
want to decide if I care; that's what our client will be doing.

4.  Closely related to #3, we need some means of signalling between a
requestor and a responder in order for the requestor to determine if use
of a nonce would be accepted.
[rmh] I don't care about this, this assumes a server controls the
clients which doesn't seem to be realistic.


Anyone disagree?

Below is the specific list of respondents to poll.  Did I miss anybody?


NOT BROKEN
----------
Marius Marian, Politenico di Torino
Ryan Hurst, Microsoft
Yasir Khan, Ascertia
Miguel Rodriguez, SeguriDATA
Peter Gutman, (doing what Peter does)
Eric Wertz, RSA
Florian Oelmaier, SyTrust
Terry Hayes, Netscape
Stephen Henson, OpenSSL


BROKEN DUE TO CACHING
---------------------
Alex Deacon, VeriSign
David Engberg, CoreStreet


Mike







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91JvnKP098932 for <[e-mail]>; Wed, 1 Oct 2003 12:57:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91Jvn0u098930 for ietf-pkix-bks; Wed, 1 Oct 2003 12:57:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91JvfKP098922 for <[e-mail]>; Wed, 1 Oct 2003 12:57:47 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h91JvVsb288654; Wed, 1 Oct 2003 15:57:31 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h91JvUQX209880; Wed, 1 Oct 2003 15:57:30 -0400
To: "Michael Myers" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Nonce encoding (was RE: OCSP response pre-production)
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 1 Oct 2003 15:56:56 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 JHEG5P4HSL JBONL5L8FGD MIAS5MHLYW|August 26, 2003) at 10/01/2003 15:57:30, Serialize complete at 10/01/2003 15:57:30
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        As far as I can tell, there is no explicit definition of the 
syntax of the nonce in RFC 2560.  If the syntax is actually OCTET STRING, 
we might be able to extend it as follows:
CHOICE  {
        requiredInResp          OCTET STRING,
        optionalInResp  [1]     EXPLICIT OCTET STRING
}
        which might not break existing code.  Or it could be
CHOICE  {
        original                        OCTET STRING,           -- 
undefined as to mandatory vs. optional in response.
        requiredInResp [0]      EXPLICIT OCTET STRING,
        optionalInResp  [1]     EXPLICIT OCTET STRING
}


                Tom Gindin





"Michael Myers" <[e-mail]>
Sent by: [e-mail]
09/26/2003 06:25 PM

 
        To:     "Deacon, Alex" <[e-mail]>, <[e-mail]>
        cc: 
        Subject:        RE: OCSP response pre-production




Alex,

I will, once I get them all integrated.  Given the volume of
today's discussions, that will likely be sometime early next
week.

Mike



> -----Original Message-----
> From: Deacon, Alex [mailto:[e-mail]]
> Sent: Friday, September 26, 2003 3:13 PM
> To: 'Michael Myers'; Deacon, Alex; [e-mail]
> Subject: RE: OCSP response pre-production
>
>
>
> Mike,
>
> As there has been some suggested changes to the text,
> can you post the most
> recent wording to get everyone back on the same page?
>
> Thanks
> Alex
>
>
> > -----Original Message-----
> > From: Michael Myers [mailto:[e-mail]]
> > Sent: Friday, September 26, 2003 2:35 PM
> > To: Deacon, Alex; [e-mail]
> > Subject: RE: OCSP response pre-production
> >
> >
> > Alex,
> >
> > I'm willing to discuss client-side "nonce
> capability discovery"
> > via this mechanism but it's clearly a v2 proposition.
> > Meanwhile, we're working to clarify what we meant
> in v1 when we
> > defined nonces in the first place.  The poll
> clearly establishes
> > a nearly unanimous consensus that the common
> understanding in
> > place at the time found its way into running code
> in all but, to
> > date, one case.  I propose we proceed on this basis.
> >
> > Mike
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Deacon, Alex [mailto:[e-mail]]
> > > Sent: Friday, September 26, 2003 2:09 PM
> > > To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> > > Myers; David Engberg;
> > > [e-mail]; Ambarish Malpani; [e-mail]
> > > Cc: Russ Housley; Stephen Kent; Tim Polk
> > > Subject: RE: OCSP response pre-production
> > >
> > >
> > >
> > > This summary assumes that the OCSP responder has
> > > control of the OCSP clients.  This may not be the
> > > case, especially when responding to OCSP requests
> > > for certs issued from SSL CA's (i.e. every flavor
> > > of browser/ocsp client on earth).  As I stated in
> > > my response to Russ, the responder could reject a
> > > request with a nonce, but why not reply with a
> > > request without a nonce, and let the client decided
> > > if it wants to accept or reject it.  If a client
> > > requires that the nonce in the result, the result
> > > is the same, the response is rejected.
> > >
> > > Alex
> >
> >
>
>







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91HSnKP093522 for <[e-mail]>; Wed, 1 Oct 2003 10:28:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91HSnO9093521 for ietf-pkix-bks; Wed, 1 Oct 2003 10:28:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91HSmKP093516 for <[e-mail]>; Wed, 1 Oct 2003 10:28:48 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h91HSnt21737; Wed, 1 Oct 2003 10:28:49 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Ambarish Malpani" <[e-mail]>
Subject: RE: SUMMARY of  nonces in OCSP
Date: Wed, 1 Oct 2003 10:32:14 -0700
Message-ID: <[e-mail]>
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: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Oops.  I missed Ambarish and Valicert as NOT BROKEN.  Sorry,
Ambarish.



> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, October 01, 2003 10:20 AM
> To: [e-mail]
> Subject: SUMMARY of nonces in OCSP
>
>
> All,
>
> Towards consensus on a path forward, here's where we
> are with the poll and recent discussions:
>
> 1.  Nonces break caching.  No news there.
>
> 2.  Of the eleven responding implementors to the poll
> regarding normative language in 2560 on the use of
> nonces, nine are not broken by the proposed language
> while two rely on a caching.
>
> 3.  We need to define an error value specific to a
> responder's inability to accept a nonce.
>
> 4.  Closely related to #3, we need some means of
> signalling between a requestor and a responder in
> order for the requestor to determine if use of a
> nonce would be accepted.
>
> Anyone disagree?
>
> Below is the specific list of respondents to poll.
> Did I miss anybody?
>
>
> NOT BROKEN
> ----------
> Marius Marian, Politenico di Torino
> Ryan Hurst, Microsoft
> Yasir Khan, Ascertia
> Miguel Rodriguez, SeguriDATA
> Peter Gutman, (doing what Peter does)
> Eric Wertz, RSA
> Florian Oelmaier, SyTrust
> Terry Hayes, Netscape
> Stephen Henson, OpenSSL
>
>
> BROKEN DUE TO CACHING
> ---------------------
> Alex Deacon, VeriSign
> David Engberg, CoreStreet
>
>
> Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91HGkKP092872 for <[e-mail]>; Wed, 1 Oct 2003 10:16:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h91HGjd7092871 for ietf-pkix-bks; Wed, 1 Oct 2003 10:16:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h91HGiKP092864 for <[e-mail]>; Wed, 1 Oct 2003 10:16:44 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h91HGjt21168 for <[e-mail]>; Wed, 1 Oct 2003 10:16:45 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: SUMMARY of  nonces in OCSP
Date: Wed, 1 Oct 2003 10:20:11 -0700
Message-ID: <[e-mail]>
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: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Towards consensus on a path forward, here's where we are with
the poll and recent discussions:

1.  Nonces break caching.  No news there.

2.  Of the eleven responding implementors to the poll regarding
normative language in 2560 on the use of nonces, nine are not
broken by the proposed language while two rely on a caching.

3.  We need to define an error value specific to a responder's
inability to accept a nonce.

4.  Closely related to #3, we need some means of signalling
between a requestor and a responder in order for the requestor
to determine if use of a nonce would be accepted.

Anyone disagree?

Below is the specific list of respondents to poll.  Did I miss
anybody?


NOT BROKEN
----------
Marius Marian, Politenico di Torino
Ryan Hurst, Microsoft
Yasir Khan, Ascertia
Miguel Rodriguez, SeguriDATA
Peter Gutman, (doing what Peter does)
Eric Wertz, RSA
Florian Oelmaier, SyTrust
Terry Hayes, Netscape
Stephen Henson, OpenSSL


BROKEN DUE TO CACHING
---------------------
Alex Deacon, VeriSign
David Engberg, CoreStreet


Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h918rxKP074405 for <[e-mail]>; Wed, 1 Oct 2003 01:53:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h918rxPI074404 for ietf-pkix-bks; Wed, 1 Oct 2003 01:53:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h918roKP074380 for <[e-mail]>; Wed, 1 Oct 2003 01:53:56 -0700 (PDT) (envelope-from [e-mail])
Received: from ms7.chttl.com.tw (ms7 [10.144.2.117]) by fw.chttl.com.tw (8.12.9/8.12.9) with ESMTP id h918rWnJ009593; Wed, 1 Oct 2003 16:53:32 +0800
Received: (from root@localhost) by ms7.chttl.com.tw (8.12.3/8.12.1) id h918rV51000740; Wed, 1 Oct 2003 16:53:31 +0800
Received: from wcwang ([10.144.133.79]) by ms7.chttl.com.tw (8.12.3/8.12.1) with SMTP id h918rRPU000619; Wed, 1 Oct 2003 16:53:31 +0800
Message-ID: <00d301c387f9$547e36b0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Faisal Maqsood" <[e-mail]>, <[e-mail]>
References: <001801c3875b$970ed050$[e-mail]>
Subject: Re: Self-Issued certificate requirements?
Date: Wed, 1 Oct 2003 16:52:20 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01C3883C.61144700"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00D0_01C3883C.61144700
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Faisal,

According to the X.509 standard 4th edition, there are three types of =
self-issued certificate:
  a) self-signed certificate (a special case of self-issued =
certificates)
  b) self-issued end certificate
  c) self-issued intermediate certificate

(Please refer to section 8.1.5 of the X.509 standard 4th edition.)

The definifion of self-issued certificate in RFC 3280 is not aligned =
with its definition in the
X.509 standard. The so-called self-issued certificates in RFC 3280 are =
mostly of type c) in
the X.509 standard. IMHO, currently both X.509 standard and PKIX have no =
clear
definition for the format and the handling of self-issued certificates =
of type b).

For self-issued certificates of type c), I believe that the requirement =
is hidden in steps
(k) and (n) of section 6.1.4 of RFC 3280 as:

  (k) Verify that the certificate is a CA certificate (as specified
        in a basicConstraints extension or as verified out-of-band).

  (n) If a key usage extension is present, verify that the
        keyCertSign bit is set.

Note that rules (k) and (n) apply to all intermediate certificates even =
if they are self-issued.

My interpretations to these two rule are:

For a v3 intermediate certificate (self-issued or not), it should =
contain a basicConstraints extension
with cA=3DTRUE. For a v1 intermediate certificate (self-issued or not), =
the RP need an out-of-band
method to make sure that it is a CA certificate.

For a v3 intermediate certificate (self-issued or not), it should =
contain a keyUsage extension
with keyCertSign bit asserted. For a v1 intermediate certificate =
(self-issued or not), there is no
need to check the key usage but the RP must make sure that it is a CA =
certificate.

Regards,
Wen-Cheng Wang

  ----- Original Message -----=20
  From: Faisal Maqsood=20
  To: [e-mail]=20
  Sent: Tuesday, September 30, 2003 10:03 PM
  Subject: Self-Issued certificate requirements?


  Hi All,

  RFC-3280 defines Self Signed certificate as:
  "A certificate is self-issued if the DNs that appear in the subject =
and issuer fields are  identical and are not empty."

  There might be two condition for self-issued certificate:
    1.. Version-1 certificate and has not any extension.=20
    2.. Version-3 certificate with set of extension/s.
  For version-1 it is clear but are there any extra required things for =
version-3 self-issued certificates?
  I mean for self-issued certificate is there any requirement that it =
Must be a CA certificate?
  I mean BasicConstraints =3D ?, Path Length =3D ?, KeyUsage =3D ? etc.

  Regards,
  FAISAL MAQSOOD

------=_NextPart_000_00D0_01C3883C.61144700
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252"><BASE=20
href=3D"file://F:\___Faisal-Data-Priv\Email Signature\">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>Faisal,</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>According to the =
X.509 standard 4th edition, there are=20
three types of self-issued certificate:</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>&nbsp; a) self-signed =
certificate (a special case of=20
self-issued certificates)</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>&nbsp; b) self-issued =
end certificate</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>&nbsp; c) self-issued =
intermediate certificate</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>(Please refer to =
section 8.1.5 of the X.509 standard 4th=20
edition.)</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>The definifion of =
self-issued certificate in RFC 3280 is=20
not aligned with its definition in the</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>X.509 standard. The =
so-called self-issued certificates in=20
RFC 3280 are mostly of type&nbsp;c) in</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>the X.509 =
standard.</FONT>&nbsp;<FONT =
face=3D&#26032;&#32048;&#26126;&#39636;>IMHO,=20
currently both X.509 standard and PKIX have no clear</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>definition for the =
format and the handling of self-issued=20
certificates of type b).</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>For self-issued =
</FONT><FONT face=3D&#26032;&#32048;&#26126;&#39636;>certificates of =
type=20
c), I believe that the requirement is hidden&nbsp;in steps</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>(k) and (n) of =
section </FONT><FONT face=3D&#26032;&#32048;&#26126;&#39636;>6.1.4 of =
RFC=20
3280 as:</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>&nbsp; =
(k)&nbsp;Verify that the certificate is a CA=20
certificate (as =
specified<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in=20
a basicConstraints extension or as verified out-of-band).</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>&nbsp; (n)&nbsp;If a =
key usage extension is present, verify=20
that the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;keyCertSign =
bit is=20
set.</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>Note that rules (k) =
and (n) apply to all intermediate=20
certificates even if they are self-issued.</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>My interpretations to =
these two rule are:</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>For a v3 intermediate =
certificate (self-issued or not), it=20
should contain a basicConstraints extension</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>with cA=3DTRUE. For a =
v1 intermediate certificate=20
(self-issued or not), the RP need an out-of-band</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>method to make sure =
that it is a CA=20
certificate.</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>For a v3 intermediate =
certificate (self-issued or not), it=20
should contain a&nbsp;keyUsage extension</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>with keyCertSign bit =
asserted. For a v1 intermediate=20
certificate (self-issued or not), there is no</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>need to check the key =
usage but the RP must&nbsp;make=20
</FONT><FONT face=3D&#26032;&#32048;&#26126;&#39636;>sure that it is a =
CA certificate.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Wen-Cheng Wang</DIV></FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;; font-color: black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Faisal Maqsood</A> </DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>To:</B> =
<A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Sent:</B> Tuesday, September 30, =
2003 10:03=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Subject:</B> Self-Issued =
certificate=20
  requirements?</DIV>
  <DIV><BR></DIV>
  <DIV>Hi All,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>RFC-3280 defines Self Signed certificate as:</DIV>
  <DIV>"<EM>A certificate is self-issued if the DNs that appear in the =
subject=20
  and issuer fields are &nbsp;identical and are not empty.</EM>"</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>There might be two condition for self-issued certificate:</DIV>
  <OL>
    <LI>Version-1 certificate and has not any extension.=20
    <LI>Version-3 certificate with set of extension/s.</LI></OL>
  <DIV>For version-1 it is clear but are there any extra required things =
for=20
  version-3 self-issued certificates?</DIV>
  <DIV>I mean for self-issued certificate is there any requirement that=20
  it&nbsp;Must be a CA certificate?</DIV>
  <DIV>I mean BasicConstraints =3D ?, Path Length =3D ?, KeyUsage =3D ? =
etc.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Regards,</DIV>
  <DIV>FAISAL MAQSOOD</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00D0_01C3883C.61144700--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h918q5KP074340 for <[e-mail]>; Wed, 1 Oct 2003 01:52:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h918q5qi074339 for ietf-pkix-bks; Wed, 1 Oct 2003 01:52:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from tessla.levonline.com (ns3.levonline.com [217.70.32.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h918q2KP074330 for <[e-mail]>; Wed, 1 Oct 2003 01:52:03 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [[UNIX: localhost]]) by tessla.levonline.com (8.11.6/8.11.6) id h918q4525945; Wed, 1 Oct 2003 10:52:04 +0200
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
Date: Wed, 01 Oct 2003 10:52:04 +0300
User-Agent: IMHO/0.98.3 (Webmail for Roxen)
Subject: Re: Self-Issued certificate =?windows-1252?q?requirements=3F?=
From: Lars Johansson <[e-mail]>
Content-Type: text/plain; charset=windows-1252
X-Originating-IP: [137.61.234.225]
MIME-Version: 1.0
To: Faisal Maqsood  <[e-mail]>
In-Reply-To: <001801c3875b$970ed050$[e-mail]>
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Faisal,

According to RFC 2510, chapter 3.2.5, self-signed certificates
should be constructed with the following requirements:

" The fields within this certificate are restricted as follows:

   - The certificate MUST be self-signed  (i.e., the signature must be
     verifiable using the SubjectPublicKeyInfo field);
   - The subject and issuer fields MUST be identical;
   - If the subject field is NULL then both subjectAltNames and
     issuerAltNames extensions MUST be present and have exactly the
same
     value;
   - The values of all other extensions must be suitable for a self-
     signed certificate (e.g., key identifiers for subject and issuer
     must be the same).
"

That's all I've been able to find.

Regards
/Lars
_________________________________________________
Lars Johansson | Consultant
[e-mail] | www.omegapoint.se
phone [phone] | fax [phone]
Omegapoint AB, Stockholm, Sweden

-------------------
> Hi All,
> 
> RFC-3280 defines Self Signed certificate as:
> "A certificate is self-issued if the DNs that appear in the subject
and issuer fields are  identical and are not empty."
> 
> There might be two condition for self-issued certificate:
>   1.. Version-1 certificate and has not any extension.
>   2.. Version-3 certificate with set of extension/s.
> For version-1 it is clear but are there any extra required things
for version-3 self-issued certificates?
> I mean for self-issued certificate is there any requirement that it
Must be a CA certificate?
> I mean BasicConstraints = ?, Path Length = ?, KeyUsage = ? etc.
> 
> Regards,
> FAISAL MAQSOOD
> 
>