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:kent@bbn.com]
Sent: 31 October 2003 19:35
To: Jean-Marc Desperrier
Cc: ietf-pkix@imc.org
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: +353-1-2843233  FAX: +353-1-2843220  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 <ietf-pkix-bks@above.proper.com>; Fri, 31 Oct 2003 15:29:26 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 31 Oct 2003 15:29:25 -0800 (PST) (envelope-from Pierre.Heuze@CardBase.com)
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 <Pierre.Heuze@CardBase.com>
To: Stephen Kent <kent@bbn.com>, Jean-Marc Desperrier <jmdesp@free.fr>
Cc: ietf-pkix@imc.org
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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:kent@bbn.com]
Sent: 31 October 2003 19:35
To: Jean-Marc Desperrier
Cc: ietf-pkix@imc.org
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: +353-1-2843233  FAX: +353-1-2843220  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 <ietf-pkix-bks@above.proper.com>; Fri, 31 Oct 2003 13:55:00 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 31 Oct 2003 13:54:59 -0800 (PST) (envelope-from anders.rundgren@telia.com)
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" <anders.rundgren@telia.com>
To: "Jean-Marc Desperrier" <jmdesp@free.fr>, "Stephen Kent" <kent@bbn.com>
Cc: <ietf-pkix@imc.org>
References: <00e101c39fc2$a59fa200$3a1b40d5@arport> <p06002003bbc83730f4f9@[128.89.89.75]> <3FA2A6BF.2040107@free.fr> <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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

>>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 <ietf-pkix-bks@above.proper.com>; Fri, 31 Oct 2003 11:39:52 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 31 Oct 2003 11:39:51 -0800 (PST) (envelope-from kent@bbn.com)
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: kent@po2.bbn.com
Message-Id: <p0600200bbbc8676a42ac@[128.89.89.75]>
In-Reply-To: <3FA2A6BF.2040107@free.fr>
References: <00e101c39fc2$a59fa200$3a1b40d5@arport> <p06002003bbc83730f4f9@[128.89.89.75]> <3FA2A6BF.2040107@free.fr>
Date: Fri, 31 Oct 2003 14:34:38 -0500
To: Jean-Marc Desperrier <jmdesp@free.fr>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Web-PKI Keygen/Certreq Questions
Cc: ietf-pkix@imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Fri, 31 Oct 2003 10:14:57 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 31 Oct 2003 10:14:55 -0800 (PST) (envelope-from jmdesp@free.fr)
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 <ietf-pkix@imc.org>; Fri, 31 Oct 2003 19:14:51 +0100
Message-ID: <3FA2A6BF.2040107@free.fr>
Date: Fri, 31 Oct 2003 19:15:27 +0100
From: Jean-Marc Desperrier <jmdesp@free.fr>
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: ietf-pkix@imc.org
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Fri, 31 Oct 2003 08:04:53 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 31 Oct 2003 08:04:51 -0800 (PST) (envelope-from kent@bbn.com)
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: kent@po2.bbn.com
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" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Web-PKI Keygen/Certreq Questions
Cc: <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Fri, 31 Oct 2003 07:47:12 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 31 Oct 2003 07:47:10 -0800 (PST) (envelope-from tim.polk@nist.gov)
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 <ietf-pkix@imc.org>; Fri, 31 Oct 2003 10:46:39 -0500 (EST)
Message-Id: <5.1.0.14.2.20031031104422.02f6ce28@email.nist.gov>
X-Sender: wpolk@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 31 Oct 2003 10:46:22 -0500
To: ietf-pkix@imc.org
From: Tim Polk <tim.polk@nist.gov>
Subject: Draft PKIX Agenda for 58th IETF
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <kent@bbn.com>, Tim Polk <tim.polk@nist.gov>


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 <ietf-pkix-bks@above.proper.com>; Fri, 31 Oct 2003 07:24:36 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 31 Oct 2003 07:24:35 -0800 (PST) (envelope-from anders.rundgren@telia.com)
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 <ietf-pkix@imc.org>; Fri, 31 Oct 2003 16:24:31 +0100 (CET)
Message-ID: <00e101c39fc2$a59fa200$3a1b40d5@arport>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Thu, 30 Oct 2003 18:36:19 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 18:36:18 -0800 (PST) (envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0600206ebbc779d9d3fe@[63.202.92.152]>
In-Reply-To: <3FA1B4A8.90101@cablespeed.com>
References: <007501c39f00$60446fa0$667f509c@hq.orionsec.com> <3FA1B4A8.90101@cablespeed.com>
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: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Request change in son-of-rfc2633
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Thu, 30 Oct 2003 17:01:53 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 17:01:52 -0800 (PST) (envelope-from jimhei@cablespeed.com)
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: <3FA1B4A8.90101@cablespeed.com>
Date: Thu, 30 Oct 2003 20:02:32 -0500
From: jim <jimhei@cablespeed.com>
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 <chokhani@orionsec.com>
CC: ietf-pkix@imc.org
Subject: Re: Request change in son-of-rfc2633
References: <007501c39f00$60446fa0$667f509c@hq.orionsec.com>
Content-Type: multipart/alternative; boundary="------------040505080708010004040903"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

--------------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:Tom.Biskupic@baltimore.com] 
>Sent: Thursday, October 30, 2003 1:29 AM
>To: 'Santosh Chokhani'; ietf-pkix@imc.org
>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:chokhani@orionsec.com]
>>Sent: Thursday, 30 October 2003 07:51
>>To: ietf-pkix@imc.org; ietf-smime@imc.org
>>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: owner-ietf-pkix@mail.imc.org 
>>[mailto:owner-ietf-pkix@mail.imc.org]
>>On Behalf Of Steve Hanna
>>Sent: Wednesday, October 29, 2003 9:58 AM
>>To: Peter Gutmann
>>Cc: ejnorman@doit.wisc.edu; ietf-pkix@imc.org; ietf-smime@imc.org
>>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 <ejnorman@doit.wisc.edu> 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$667f509c@hq.orionsec.com">
  <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:Tom.Biskupic@baltimore.com">mailto:Tom.Biskupic@baltimore.com</a>] 
Sent: Thursday, October 30, 2003 1:29 AM
To: 'Santosh Chokhani'; <a class="moz-txt-link-abbreviated" href="mailto:ietf-pkix@imc.org">ietf-pkix@imc.org</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:chokhani@orionsec.com">mailto:chokhani@orionsec.com</a>]
Sent: Thursday, 30 October 2003 07:51
To: <a class="moz-txt-link-abbreviated" href="mailto:ietf-pkix@imc.org">ietf-pkix@imc.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:ietf-smime@imc.org">ietf-smime@imc.org</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:owner-ietf-pkix@mail.imc.org">owner-ietf-pkix@mail.imc.org</a> 
[<a class="moz-txt-link-freetext" href="mailto:owner-ietf-pkix@mail.imc.org">mailto:owner-ietf-pkix@mail.imc.org</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:ejnorman@doit.wisc.edu">ejnorman@doit.wisc.edu</a>; <a class="moz-txt-link-abbreviated" href="mailto:ietf-pkix@imc.org">ietf-pkix@imc.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:ietf-smime@imc.org">ietf-smime@imc.org</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:ejnorman@doit.wisc.edu">&lt;ejnorman@doit.wisc.edu&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 <ietf-pkix-bks@above.proper.com>; Thu, 30 Oct 2003 16:05:00 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 16:04:58 -0800 (PST) (envelope-from tgindin@us.ibm.com)
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" <mmyers@fastq.com>
Cc: "David Engberg" <dave@corestreet.com>, ietf-pkix@imc.org
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 <tgindin@us.ibm.com>
Message-ID: <OF55E2C2E3.5C5A3AA6-ON85256DC7.0061EB2C-85256DD0.00006142@us.ibm.com>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

        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" <mmyers@fastq.com>
10/22/2003 12:49 PM

 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     "David Engberg" <dave@corestreet.com>, <ietf-pkix@imc.org>
        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:tgindin@us.ibm.com]
> Sent: Wednesday, October 22, 2003 9:19 AM
> To: Michael Myers
> Cc: David Engberg; ietf-pkix@imc.org
> 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 <ietf-pkix-bks@above.proper.com>; Thu, 30 Oct 2003 08:44:34 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 08:44:31 -0800 (PST) (envelope-from anders.rundgren@telia.com)
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" <anders.rundgren@telia.com>
To: "Karl Scheibelhofer" <karl.scheibelhofer@iaik.tugraz.at>, "Florian Oelmaier" <oelmaier@sytrust.com>, <ietf-pkix@imc.org>
Cc: "'James Jing'" <jjing@securenet.com.au>, "'Markus Lorch'" <mlorch@vt.edu>
References: <000101c39e38$ee9e6120$4228a8c0@hagen> <011001c39eec$96588540$d21a40d5@arport> <00d401c39f00$e1c275e0$51981b81@iaik.at>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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" <karl.scheibelhofer@iaik.tugraz.at>
To: "Anders Rundgren" <anders.rundgren@telia.com>; "Florian Oelmaier" <oelmaier@sytrust.com>; <ietf-pkix@imc.org>
Cc: "'James Jing'" <jjing@securenet.com.au>; "'Markus Lorch'" <mlorch@vt.edu>
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: +43 316 873 5520
http://jce.iaik.tugraz.at


----- Original Message ----- 
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: "Florian Oelmaier" <oelmaier@sytrust.com>; <ietf-pkix@imc.org>
Cc: "'James Jing'" <jjing@securenet.com.au>; "'Markus Lorch'"
<mlorch@vt.edu>
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" <oelmaier@sytrust.com>
> To: "'Anders Rundgren'" <anders.rundgren@telia.com>; "'James Jing'"
<jjing@securenet.com.au>; "'Markus Lorch'" <mlorch@vt.edu>;
> <ietf-pkix@imc.org>
> 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 <ietf-pkix-bks@above.proper.com>; Thu, 30 Oct 2003 08:27:06 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 08:27:05 -0800 (PST) (envelope-from chokhani@orionsec.com)
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 11:11:00 -0500 
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: Request change in son-of-rfc2633
Date: Thu, 30 Oct 2003 11:10:57 -0500
Message-ID: <007901c39f00$67ee9050$667f509c@hq.orionsec.com>
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: <OFE2F4CDFF.779487E7-ON85256DCF.004DF031@internalgroove.net>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: Walt_Tuvell@groove.net [mailto:Walt_Tuvell@groove.net] 
Sent: Thursday, October 30, 2003 9:19 AM
To: Santosh Chokhani
Cc: ietf-pkix@imc.org
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 <ietf-pkix-bks@above.proper.com>; Thu, 30 Oct 2003 08:18:07 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 08:18:06 -0800 (PST) (envelope-from chokhani@orionsec.com)
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 11:10:47 -0500 
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: Request change in son-of-rfc2633
Date: Thu, 30 Oct 2003 11:10:12 -0500
Message-ID: <007501c39f00$60446fa0$667f509c@hq.orionsec.com>
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: <119C85693DF1D4119E800002A5097D01C06C7C@irlms03.ie.baltimore.com>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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:Tom.Biskupic@baltimore.com] 
Sent: Thursday, October 30, 2003 1:29 AM
To: 'Santosh Chokhani'; ietf-pkix@imc.org
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:chokhani@orionsec.com]
> Sent: Thursday, 30 October 2003 07:51
> To: ietf-pkix@imc.org; ietf-smime@imc.org
> 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: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Steve Hanna
> Sent: Wednesday, October 29, 2003 9:58 AM
> To: Peter Gutmann
> Cc: ejnorman@doit.wisc.edu; ietf-pkix@imc.org; ietf-smime@imc.org
> 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 <ejnorman@doit.wisc.edu> 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 <ietf-pkix-bks@above.proper.com>; Thu, 30 Oct 2003 06:19:25 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 06:19:24 -0800 (PST) (envelope-from Walt_Tuvell@groove.net)
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: Walt_Tuvell@groove.net
Subject: RE: Request change in son-of-rfc2633
To: "Santosh Chokhani" <chokhani@orionsec.com>
Cc: <ietf-pkix@imc.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFE2F4CDFF.779487E7-ON85256DCF.004DF031@internalgroove.net>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

> 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 <ietf-pkix-bks@above.proper.com>; Thu, 30 Oct 2003 05:52:14 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 05:52:13 -0800 (PST) (envelope-from anders.rundgren@telia.com)
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" <anders.rundgren@telia.com>
To: "Florian Oelmaier" <oelmaier@sytrust.com>, <ietf-pkix@imc.org>
Cc: "'James Jing'" <jjing@securenet.com.au>, "'Markus Lorch'" <mlorch@vt.edu>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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" <oelmaier@sytrust.com>
To: "'Anders Rundgren'" <anders.rundgren@telia.com>; "'James Jing'" <jjing@securenet.com.au>; "'Markus Lorch'" <mlorch@vt.edu>;
<ietf-pkix@imc.org>
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 <ietf-pkix-bks@above.proper.com>; Thu, 30 Oct 2003 04:05:40 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Thu, 30 Oct 2003 04:05:39 -0800 (PST) (envelope-from Tom.Biskupic@baltimore.com)
Received: from Baltimore-FW2 ([172.19.1.2]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h9UBuoQ11724 for <ietf-pkix@imc.org>; 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 <T659947daa00a9919350d2@emeairlsw1.baltimore.com> for <ietf-pkix@imc.org>; 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: <119C85693DF1D4119E800002A5097D01C06C7F@irlms03.ie.baltimore.com>
From: Tom Biskupic <Tom.Biskupic@baltimore.com>
To: "'Santosh Chokhani'" <chokhani@orionsec.com>, ietf-pkix@imc.org
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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:Tom.Biskupic@baltimore.com]
> Sent: Thursday, 30 October 2003 17:29
> To: 'Santosh Chokhani'; ietf-pkix@imc.org
> 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:chokhani@orionsec.com]
> > Sent: Thursday, 30 October 2003 07:51
> > To: ietf-pkix@imc.org; ietf-smime@imc.org
> > 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: owner-ietf-pkix@mail.imc.org 
> > [mailto:owner-ietf-pkix@mail.imc.org]
> > On Behalf Of Steve Hanna
> > Sent: Wednesday, October 29, 2003 9:58 AM
> > To: Peter Gutmann
> > Cc: ejnorman@doit.wisc.edu; ietf-pkix@imc.org; ietf-smime@imc.org
> > 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 <ejnorman@doit.wisc.edu> 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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 22:37:39 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 29 Oct 2003 22:37:37 -0800 (PST) (envelope-from Tom.Biskupic@baltimore.com)
Received: from Baltimore-FW2 ([172.19.1.2]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h9U6TfQ09676 for <ietf-pkix@imc.org>; 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 <T65981c4fa50a9919350d2@emeairlsw1.baltimore.com> for <ietf-pkix@imc.org>; 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: <119C85693DF1D4119E800002A5097D01C06C7C@irlms03.ie.baltimore.com>
From: Tom Biskupic <Tom.Biskupic@baltimore.com>
To: "'Santosh Chokhani'" <chokhani@orionsec.com>, ietf-pkix@imc.org
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 20:02:54 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 pgut001@cs.auckland.ac.nz)
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: <200310300405.h9U45FK16114@cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: pgut001@cs.auckland.ac.nz, steve.hanna@sun.com
Subject: Re: Request change in son-of-rfc2633
Cc: ejnorman@doit.wisc.edu, ietf-pkix@imc.org, ietf-smime@imc.org
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Steve Hanna <steve.hanna@sun.com> 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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 18:31:59 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 29 Oct 2003 18:31:58 -0800 (PST) (envelope-from kent@bbn.com)
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" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Standards for Web-signing II
Cc: <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 12:53:27 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 chokhani@orionsec.com)
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" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>, <ietf-smime@imc.org>
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$667f509c@hq.orionsec.com>
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: <3F9FD56A.771A262C@sun.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
On Behalf Of Steve Hanna
Sent: Wednesday, October 29, 2003 9:58 AM
To: Peter Gutmann
Cc: ejnorman@doit.wisc.edu; ietf-pkix@imc.org; ietf-smime@imc.org
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 <ejnorman@doit.wisc.edu> 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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 08:32:47 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 29 Oct 2003 08:32:46 -0800 (PST) (envelope-from anders.rundgren@telia.com)
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" <anders.rundgren@telia.com>
To: "Stephen Kent" <kent@bbn.com>
Cc: <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

>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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 08:23:13 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 29 Oct 2003 08:23:11 -0800 (PST) (envelope-from oelmaier@sytrust.com)
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" <oelmaier@sytrust.com>
To: "'Anders Rundgren'" <anders.rundgren@telia.com>, "'James Jing'" <jjing@securenet.com.au>, "'Markus Lorch'" <mlorch@vt.edu>, <ietf-pkix@imc.org>
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: VUfdcyZGoeXF5nFopPSwfEaUhvUSh3O-qgFSAPLA9qsKvuxM92bzZ2@t-dialin.net
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

> 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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 06:58:41 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 steve.hanna@sun.com)
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: <3F9FD56A.771A262C@sun.com>
Date: Wed, 29 Oct 2003 09:57:46 -0500
From: Steve Hanna <steve.hanna@sun.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
CC: ejnorman@doit.wisc.edu, ietf-pkix@imc.org, ietf-smime@imc.org
Subject: Re: Request change in son-of-rfc2633
References: <200310290337.h9T3bu208738@cs.auckland.ac.nz>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms58E8539260192E6D326EA0C4"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ejnorman@doit.wisc.edu> 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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 06:57:02 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 29 Oct 2003 06:57:01 -0800 (PST) (envelope-from kent@bbn.com)
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: kent@po2.bbn.com
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" <anders.rundgren@telia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Standards for Web-signing II
Cc: <ietf-pkix@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 06:54:45 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 29 Oct 2003 06:54:43 -0800 (PST) (envelope-from schwebler@trustcenter.de)
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: <3F9FD469.7934202D@trustcenter.de>
Date: Wed, 29 Oct 2003 15:53:29 +0100
From: Hans-Peter Schwebler <schwebler@trustcenter.de>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Jing <jjing@securenet.com.au>
CC: Anders Rundgren <anders.rundgren@telia.com>, ietf-pkix@imc.org
Subject: Re: Standards for Web-signing II
References: <85DA9C6C3DD8C74F8A8611815C635F8D4151FA@AMALTHEA.securenet.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 05:09:41 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 29 Oct 2003 05:09:40 -0800 (PST) (envelope-from anders.rundgren@telia.com)
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" <anders.rundgren@telia.com>
To: "Florian Oelmaier" <oelmaier@sytrust.com>, "'James Jing'" <jjing@securenet.com.au>, "'Markus Lorch'" <mlorch@vt.edu>, <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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" <oelmaier@sytrust.com>
To: "'Anders Rundgren'" <anders.rundgren@telia.com>; "'James Jing'" <jjing@securenet.com.au>; "'Markus Lorch'" <mlorch@vt.edu>;
<ietf-pkix@imc.org>
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 <ietf-pkix-bks@above.proper.com>; Wed, 29 Oct 2003 02:41:26 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 29 Oct 2003 02:41:22 -0800 (PST) (envelope-from oelmaier@sytrust.com)
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" <oelmaier@sytrust.com>
To: "'Anders Rundgren'" <anders.rundgren@telia.com>, "'James Jing'" <jjing@securenet.com.au>, "'Markus Lorch'" <mlorch@vt.edu>, <ietf-pkix@imc.org>
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: JON6EeZEwe70HluZ323FFPROaEi9O7ckcEE5VgwBQuJOTUmh0XuNga@t-dialin.net
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

> >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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 22:41:12 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 22:41:09 -0800 (PST) (envelope-from anders.rundgren@telia.com)
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" <anders.rundgren@telia.com>
To: "James Jing" <jjing@securenet.com.au>, "Markus Lorch" <mlorch@vt.edu>, <ietf-pkix@imc.org>, "Florian Oelmaier" <oelmaier@sytrust.com>
References: <85DA9C6C3DD8C74F8A8611815C635F8D4151FA@AMALTHEA.securenet.com.au>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

>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:anders.rundgren@telia.com]
Sent: Wednesday, 29 October 2003 6:59 AM
To: Markus Lorch; ietf-pkix@imc.org
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" <mlorch@vt.edu>
To: "'Anders Rundgren'" <anders.rundgren@telia.com>; <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: pki-tc@lists.oasis-open.org; ietf-pkix@imc.org; ietf-smime@imc.org
> 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" <anders.rundgren@telia.com>
> To: <pki-tc@lists.oasis-open.org>; <ietf-pkix@imc.org>; 
> <ietf-smime@imc.org>
> 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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 19:35:43 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 pgut001@cs.auckland.ac.nz)
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: <200310290337.h9T3bu208738@cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: ejnorman@doit.wisc.edu, ietf-pkix@imc.org
Subject: RE: Request change in son-of-rfc2633
Cc: ietf-smime@imc.org
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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

Eric Norman <ejnorman@doit.wisc.edu> 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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 16:37:11 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 16:37:10 -0800 (PST) (envelope-from oelmaier@sytrust.com)
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" <oelmaier@sytrust.com>
To: "'Markus Lorch'" <mlorch@vt.edu>, "'Anders Rundgren'" <anders.rundgren@telia.com>, <ietf-pkix@imc.org>
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: STC2kyZOreXEk1n2ub+BZnZQjBbTpEj91VD9J1ISav7mTuYA7vIF8E@t-dialin.net
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

> > 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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 15:04:07 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 15:04:05 -0800 (PST) (envelope-from jjing@securenet.com.au)
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: <85DA9C6C3DD8C74F8A8611815C635F8D4151FA@AMALTHEA.securenet.com.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Standards for Web-signing II
Thread-Index: AcOdoQUovlAiDSCVQYitPD4AmH6OXQABNLoQ
From: "James Jing" <jjing@securenet.com.au>
To: "Anders Rundgren" <anders.rundgren@telia.com>, "Markus Lorch" <mlorch@vt.edu>, <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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:anders.rundgren@telia.com]
Sent: Wednesday, 29 October 2003 6:59 AM
To: Markus Lorch; ietf-pkix@imc.org
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" <mlorch@vt.edu>
To: "'Anders Rundgren'" <anders.rundgren@telia.com>; <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: pki-tc@lists.oasis-open.org; ietf-pkix@imc.org; ietf-smime@imc.org
> 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" <anders.rundgren@telia.com>
> To: <pki-tc@lists.oasis-open.org>; <ietf-pkix@imc.org>; 
> <ietf-smime@imc.org>
> 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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 12:44:36 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 12:44:32 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us)
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: <200310282044.PAA25364@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-02.txt
Date: Tue, 28 Oct 2003 15:44:22 -0500
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

--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:
	mailserv@ietf.org.
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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-28155813.I-D@ietf.org>

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:	<2003-10-28155813.I-D@ietf.org>

--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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 12:02:02 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 12:02:02 -0800 (PST) (envelope-from anders.rundgren@telia.com)
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" <anders.rundgren@telia.com>
To: "Markus Lorch" <mlorch@vt.edu>, <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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" <mlorch@vt.edu>
To: "'Anders Rundgren'" <anders.rundgren@telia.com>; <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: pki-tc@lists.oasis-open.org; ietf-pkix@imc.org; ietf-smime@imc.org
> 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" <anders.rundgren@telia.com>
> To: <pki-tc@lists.oasis-open.org>; <ietf-pkix@imc.org>; 
> <ietf-smime@imc.org>
> 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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 11:01:18 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 11:01:17 -0800 (PST) (envelope-from mlorch@vt.edu)
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" <mlorch@vt.edu>
To: "'Anders Rundgren'" <anders.rundgren@telia.com>, <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: pki-tc@lists.oasis-open.org; ietf-pkix@imc.org; ietf-smime@imc.org
> 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" <anders.rundgren@telia.com>
> To: <pki-tc@lists.oasis-open.org>; <ietf-pkix@imc.org>; 
> <ietf-smime@imc.org>
> 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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 09:44:06 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 09:44:05 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr)
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 <Peter.Sylvester@EdelWeb.fr>
Message-Id: <200310281743.h9SHhw419224@chandon.edelweb.fr>
To: kent@bbn.com, ietf-pkix@imc.org, trevorf@windows.microsoft.com
Subject: RE: SCVP additions
X-Sun-Charset: US-ASCII
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 06:31:12 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 06:31:07 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us)
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: <200310281430.JAA23475@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-scvp-13.txt
Date: Tue, 28 Oct 2003 09:30:56 -0500
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

--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:
	mailserv@ietf.org.
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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-28095041.I-D@ietf.org>

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:	<2003-10-28095041.I-D@ietf.org>

--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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 06:31:01 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 06:31:00 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us)
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: <200310281430.JAA23458@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-sim-01.txt
Date: Tue, 28 Oct 2003 09:30:49 -0500
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

--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:
	mailserv@ietf.org.
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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-28095028.I-D@ietf.org>

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:	<2003-10-28095028.I-D@ietf.org>

--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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 05:49:55 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 anders.rundgren@telia.com)
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" <anders.rundgren@telia.com>
To: <pki-tc@lists.oasis-open.org>, <ietf-pkix@imc.org>, <ietf-smime@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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" <anders.rundgren@telia.com>
To: <pki-tc@lists.oasis-open.org>; <ietf-pkix@imc.org>; <ietf-smime@imc.org>
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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 04:24:37 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 04:24:34 -0800 (PST) (envelope-from stefans@microsoft.com)
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: <0C3042E92D8A714783E2C44AB9936E1D766E56@EUR-MSG-03.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Finalizing sonOfRFC3039
Thread-Index: AcOdTj//uIo8VUwURhOp4GIujLpe0g==
From: "Stefan Santesson" <stefans@microsoft.com>
To: <ietf-pkix@imc.org>
Cc: "Tim Polk" <tim.polk@nist.gov>, "Nystrom, Magnus" <magnus@rsasecurity.com>
X-OriginalArrivalTime: 28 Oct 2003 12:24:27.0873 (UTC) FILETIME=[6E38C510:01C39D4E]
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Tue, 28 Oct 2003 02:51:37 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Tue, 28 Oct 2003 02:51:35 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr)
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA05258 for <ietf-pkix@imc.org>; 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 ietf-pkix@imc.org; Tue, 28 Oct 2003 11:51:26 +0100 (MET)
Date: Tue, 28 Oct 2003 11:51:26 +0100 (MET)
From: Peter Sylvester <Peter.Sylvester@EdelWeb.fr>
Message-Id: <200310281051.h9SApQ418171@chandon.edelweb.fr>
To: ietf-pkix@imc.org
Subject: RE: Request change in son-of-rfc2633
X-Sun-Charset: US-ASCII
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Mon, 27 Oct 2003 22:18:51 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Mon, 27 Oct 2003 22:18:50 -0800 (PST) (envelope-from ejnorman@doit.wisc.edu)
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 ietf-pkix@imc.org; Tue, 28 Oct 2003 00:18:53 -0600
Date: Tue, 28 Oct 2003 00:18:52 -0600 (CST)
From: Eric Norman <ejnorman@doit.wisc.edu>
To: PKIX list <ietf-pkix@imc.org>
Subject: RE: Request change in son-of-rfc2633
In-Reply-To: <200310280212.h9S2CPq01616@cs.auckland.ac.nz>
Message-ID: <Pine.A41.4.44.0310280002440.13680-100000@holstein.doit.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Mon, 27 Oct 2003 14:11:12 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Mon, 27 Oct 2003 14:11:08 -0800 (PST) (envelope-from scoya@cnri.reston.va.us)
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: <200310272210.RAA19517@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-logotypes-12.txt
Date: Mon, 27 Oct 2003 17:10:56 -0500
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

--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 ietf-pkix@imc.org
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:
	mailserv@ietf.org.
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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-27171453.I-D@ietf.org>

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:	<2003-10-27171453.I-D@ietf.org>

--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 <ietf-pkix-bks@above.proper.com>; Mon, 27 Oct 2003 06:18:49 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Mon, 27 Oct 2003 06:18:49 -0800 (PST) (envelope-from scoya@cnri.reston.va.us)
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: <200310271418.JAA14519@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-logotypes-12.txt
Date: Mon, 27 Oct 2003 09:18:38 -0500
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

--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 ietf-pkix@imc.org
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:
	mailserv@ietf.org.
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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-24160933.I-D@ietf.org>

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:	<2003-10-24160933.I-D@ietf.org>

--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 <ietf-pkix-bks@above.proper.com>; Mon, 27 Oct 2003 06:18:48 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Mon, 27 Oct 2003 06:18:46 -0800 (PST) (envelope-from scoya@cnri.reston.va.us)
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: <200310271418.JAA14506@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pkix@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pkix-logotypes-12.txt
Date: Mon, 27 Oct 2003 09:18:35 -0500
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

--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 ietf-pkix@imc.org
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:
	mailserv@ietf.org.
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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-24160933.I-D@ietf.org>

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:	<2003-10-24160933.I-D@ietf.org>

--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 <ietf-pkix-bks@above.proper.com>; Mon, 27 Oct 2003 00:37:23 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Mon, 27 Oct 2003 00:37:21 -0800 (PST) (envelope-from Denis.Pinkas@bull.net)
Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [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: <3F9CD930.9090907@bull.net>
Date: Mon, 27 Oct 2003 09:37:04 +0100
From: Denis Pinkas <Denis.Pinkas@bull.net>
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 <housley@vigilsec.com>
CC: wpolk@nist.gov, kent@bbn.com, smb@research.att.com, iesg@ietf.org, ietf-pkix@imc.org
Subject: Re: Last Call: 'Warranty Certificate Extension' to  Informational RFC
References: <5.2.0.9.2.20031023105107.03e04e30@mail.binhost.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 iesg@ietf.org or ietf@ietf.org"

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: ietf-pkix@imc.org
>> From: The IESG <iesg-secretary@ietf.org>
>> Subject: Last Call: 'Internet X.509 Public Key Infrastructure Warranty
>>          Certificate Extension' to Informational RFC
>> Reply-To: iesg@ietf.org
>> Date: Tue, 12 Aug 2003 14:44:07 -0400
>> Sender: owner-ietf-pkix@mail.imc.org
>>
>> 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
>> iesg@ietf.org or ietf@ietf.org 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 <ietf-pkix-bks@above.proper.com>; Sun, 26 Oct 2003 08:36:57 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Sun, 26 Oct 2003 08:36:56 -0800 (PST) (envelope-from dpkemp@missi.ncsc.mil)
Message-ID: <200310261623.h9QGN4D2017133@stingray.missi.ncsc.mil>
Date: Sun, 26 Oct 2003 11:36:51 -0500
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
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: ietf-pkix@imc.org
Subject: Re: AKI and SKI problem with RFC 3280?
References: <0C3042E92D8A714783E2C44AB9936E1D737284@EUR-MSG-03.europe.corp.microsoft.com>
In-Reply-To: <0C3042E92D8A714783E2C44AB9936E1D737284@EUR-MSG-03.europe.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: owner-ietf-pkix@mail.imc.org
> 
> [mailto:owner-ietf-pkix@mail.imc.org]
> 
>>On Behalf Of David P. Kemp
>>Sent: den 25 oktober 2003 00:54
>>To: ietf-pkix@imc.org
>>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: owner-ietf-pkix@mail.imc.org
> 
> [mailto:owner-ietf-pkix@mail.imc.org]
> 
>>On
>>
>>>Behalf Of David P. Kemp
>>>Sent: Friday, October 24, 2003 12:19 PM
>>>To: ietf-pkix@imc.org
>>>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 <ietf-pkix-bks@above.proper.com>; Sun, 26 Oct 2003 07:43:55 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Sun, 26 Oct 2003 07:43:54 -0800 (PST) (envelope-from dpkemp@missi.ncsc.mil)
Message-ID: <200310261530.h9QFU2D2016488@stingray.missi.ncsc.mil>
Date: Sun, 26 Oct 2003 10:43:44 -0500
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
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: ietf-pkix@imc.org
Subject: Re: AKI and SKI problem with RFC 3280?
References: <0C3042E92D8A714783E2C44AB9936E1D737284@EUR-MSG-03.europe.corp.microsoft.com>
In-Reply-To: <0C3042E92D8A714783E2C44AB9936E1D737284@EUR-MSG-03.europe.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: owner-ietf-pkix@mail.imc.org
> 
> [mailto:owner-ietf-pkix@mail.imc.org]
> 
>>On Behalf Of David P. Kemp
>>Sent: den 25 oktober 2003 00:54
>>To: ietf-pkix@imc.org
>>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: owner-ietf-pkix@mail.imc.org
> 
> [mailto:owner-ietf-pkix@mail.imc.org]
> 
>>On
>>
>>>Behalf Of David P. Kemp
>>>Sent: Friday, October 24, 2003 12:19 PM
>>>To: ietf-pkix@imc.org
>>>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 <ietf-pkix-bks@above.proper.com>; Sun, 26 Oct 2003 07:03:51 -0800 (PST) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Sun, 26 Oct 2003 07:03:50 -0800 (PST) (envelope-from chokhani@orionsec.com)
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" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Sun, 26 Oct 2003 10:03:34 -0500
Message-ID: <001501c39bd2$58d69080$3a6c5c0c@hq.orionsec.com>
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: <200310242240.h9OMeND2001715@stingray.missi.ncsc.mil>
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of David P. Kemp
Sent: Friday, October 24, 2003 6:54 PM
To: ietf-pkix@imc.org
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: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David P. Kemp
> Sent: Friday, October 24, 2003 12:19 PM
> To: ietf-pkix@imc.org
> 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 <ietf-pkix-bks@above.proper.com>; Sat, 25 Oct 2003 16:06:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Sat, 25 Oct 2003 16:06:18 -0700 (PDT) (envelope-from Gregory@netscreen.com)
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: <541402FFDC56DA499E7E13329ABFEA87E67378@SARATOGA.netscreen.com>
From: Gregory Lebovitz <Gregory@netscreen.com>
To: "'saag@mit.edu'" <saag@mit.edu>, "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Sat, 25 Oct 2003 10:43:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Sat, 25 Oct 2003 10:43:14 -0700 (PDT) (envelope-from stefans@microsoft.com)
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: <0C3042E92D8A714783E2C44AB9936E1D737284@EUR-MSG-03.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AKI and SKI problem with RFC 3280?
Thread-Index: AcOajCat2kZWqCl5SCecQsXUFOs2QwAkbnhg
From: "Stefan Santesson" <stefans@microsoft.com>
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>, <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of David P. Kemp
> Sent: den 25 oktober 2003 00:54
> To: ietf-pkix@imc.org
> 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: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On
> > Behalf Of David P. Kemp
> > Sent: Friday, October 24, 2003 12:19 PM
> > To: ietf-pkix@imc.org
> > 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 <ietf-pkix-bks@above.proper.com>; Fri, 24 Oct 2003 15:54:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 24 Oct 2003 15:54:03 -0700 (PDT) (envelope-from dpkemp@missi.ncsc.mil)
Message-ID: <200310242240.h9OMeND2001715@stingray.missi.ncsc.mil>
Date: Fri, 24 Oct 2003 18:53:53 -0400
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
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: ietf-pkix@imc.org
Subject: Re: AKI and SKI problem with RFC 3280?
References: <00c601c39a6c$769d1f60$9e00a8c0@hq.orionsec.com>
In-Reply-To: <00c601c39a6c$769d1f60$9e00a8c0@hq.orionsec.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
> Behalf Of David P. Kemp
> Sent: Friday, October 24, 2003 12:19 PM
> To: ietf-pkix@imc.org
> 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 <ietf-pkix-bks@above.proper.com>; Fri, 24 Oct 2003 13:21:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 24 Oct 2003 13:21:52 -0700 (PDT) (envelope-from chokhani@orionsec.com)
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 <ietf-pkix@imc.org>; Fri, 24 Oct 2003 16:21:53 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Fri, 24 Oct 2003 16:21:48 -0400
Message-ID: <00c601c39a6c$769d1f60$9e00a8c0@hq.orionsec.com>
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: <200310241604.h9OG4wD2020988@stingray.missi.ncsc.mil>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9OKLqI7094541
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of David P. Kemp
Sent: Friday, October 24, 2003 12:19 PM
To: ietf-pkix@imc.org
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 <ietf-pkix-bks@above.proper.com>; Fri, 24 Oct 2003 10:17:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 24 Oct 2003 10:17:04 -0700 (PDT) (envelope-from jmdesp@free.fr)
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 <ietf-pkix@imc.org>; Fri, 24 Oct 2003 19:17:03 +0200
Message-ID: <3F995EB0.2060409@free.fr>
Date: Fri, 24 Oct 2003 19:17:36 +0200
From: Jean-Marc Desperrier <jmdesp@free.fr>
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: ietf-pkix@imc.org
Subject: Re: AKI and SKI problem with RFC 3280?
References: <000601c3990a$863a5b80$6601a8c0@gnosis> <3F9934FB.8B22E6A0@sun.com>
In-Reply-To: <3F9934FB.8B22E6A0@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Fri, 24 Oct 2003 09:18:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 24 Oct 2003 09:18:38 -0700 (PDT) (envelope-from dpkemp@missi.ncsc.mil)
Message-ID: <200310241604.h9OG4wD2020988@stingray.missi.ncsc.mil>
Date: Fri, 24 Oct 2003 12:18:33 -0400
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
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: ietf-pkix@imc.org
Subject: Re: AKI and SKI problem with RFC 3280?
References: <200310211309.h9LD9YR08254@cs.auckland.ac.nz> <3F9540EB.E725568D@sun.com>
In-Reply-To: <3F9540EB.E725568D@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Fri, 24 Oct 2003 07:20:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 24 Oct 2003 07:20:10 -0700 (PDT) (envelope-from steve.hanna@sun.com)
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 <ietf-pkix@imc.org>; 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: <3F9934FB.8B22E6A0@sun.com>
Date: Fri, 24 Oct 2003 10:19:39 -0400
From: Steve Hanna <steve.hanna@sun.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix@imc.org
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Fri, 24 Oct 2003 05:23:24 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 24 Oct 2003 05:23:21 -0700 (PDT) (envelope-from wpolk@nist.gov)
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 ietf-pkix@imc.org; Fri, 24 Oct 2003 08:23:02 -0400 (EDT)
Received: from 151.200.235.112 ( [151.200.235.112]) as user wpolk@email.nist.gov by imp.nist.gov with HTTP; Fri, 24 Oct 2003 08:23:02 -0400
Message-ID: <1066998182.3f9919a625bd2@imp.nist.gov>
Date: Fri, 24 Oct 2003 08:23:02 -0400
From: wpolk@nist.gov
To: ietf-pkix@imc.org
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Fri, 24 Oct 2003 03:58:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Fri, 24 Oct 2003 03:58:51 -0700 (PDT) (envelope-from housley@vigilsec.com)
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: <5.2.0.9.2.20031023105107.03e04e30@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 23 Oct 2003 10:58:26 -0400
To: Denis.Pinkas@bull.net
From: Russ Housley <housley@vigilsec.com>
Subject: Re: Last Call: 'Warranty Certificate Extension' to Informational RFC 
Cc: wpolk@nist.gov, kent@bbn.com, smb@research.att.com, iesg@ietf.org, ietf-pkix@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: ietf-pkix@imc.org
>From: The IESG <iesg-secretary@ietf.org>
>Subject: Last Call: 'Internet X.509 Public Key Infrastructure Warranty
>          Certificate Extension' to Informational RFC
>Reply-To: iesg@ietf.org
>Date: Tue, 12 Aug 2003 14:44:07 -0400
>Sender: owner-ietf-pkix@mail.imc.org
>
>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
>iesg@ietf.org or ietf@ietf.org 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 <ietf-pkix-bks@above.proper.com>; Thu, 23 Oct 2003 05:17:33 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Thu, 23 Oct 2003 05:17:31 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [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: <3F97C6D2.3080907@bull.net>
Date: Thu, 23 Oct 2003 14:17:22 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
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 <wpolk@nist.gov>, Stephen Kent <kent@bbn.com>, Russ Housley <housley@vigilsec.com>, Steve Bellovin <smb@research.att.com>
CC: Alice Sturgeon <asturgeon@spyrus.com>, iesg@ietf.org, pkix <ietf-pkix@imc.org>
Subject: Re: Last Call: 'Warranty Certificate Extension' to Informational RFC
References: <E19me7r-0005yz-8u@asgard.ietf.org> <3F4B516C.4050607@bull.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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
>> iesg@ietf.org or ietf@ietf.org 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: owner-ietf-pkix@mail.imc.org
> [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Denis Pinkas
> Sent: Tuesday, July 29, 2003 6:38 AM
> To: asturgeon@spyrus.com
> Cc: ietf-pkix@imc.org
> 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 20:37:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 20:37:37 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz)
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: <200310230338.h9N3cap19981@cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: chokhani@orionsec.com, ietf-pkix@imc.org, pmhesse@geminisecurity.com, sharon.boeyen@entrust.com
Subject: RE: AKI and SKI problem with RFC 3280?
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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

"Stefan Santesson" <stefans@microsoft.com> 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?= <michael@stroeder.com> 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" <aarsenau@bbn.com> 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 <jmdesp@free.fr> 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 19:08:21 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 19:08:20 -0700 (PDT) (envelope-from eldub@pobox.com)
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" <eldub@pobox.com>
To: "'Steve Hanna'" <steve.hanna@sun.com>, <ietf-pkix@imc.org>
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: <3F96EF91.C1E98EEF@sun.com>
Importance: Normal
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Steve Hanna
Sent: Wednesday, October 22, 2003 1:59 PM
To: Peter Hesse
Cc: ietf-pkix@imc.org
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                    pmhesse@geminisecurity.com     |
> | Phone: (703)934-2031         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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Santosh Chokhani
> Sent: Wednesday, October 22, 2003 2:01 PM
> To: ietf-pkix@imc.org
> 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:pmhesse@geminisecurity.com]
> Sent: Wednesday, October 22, 2003 12:59 PM
> To: 'Santosh Chokhani'; ietf-pkix@imc.org
> 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 16:19:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 16:19:12 -0700 (PDT) (envelope-from chokhani@orionsec.com)
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" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 19:19:03 -0400
Message-ID: <000001c398f2$e33fc260$27655c0c@hq.orionsec.com>
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: <9A4F653B0A375841AC75A8D17712B9C9061AC63B@sottmxs04.entrust.com>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Sharon:

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

-----Original Message-----
From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] 
Sent: Wednesday, October 22, 2003 3:46 PM
To: 'Peter Hesse'; 'Santosh Chokhani'; ietf-pkix@imc.org
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:pmhesse@geminisecurity.com]
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; ietf-pkix@imc.org
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                    pmhesse@geminisecurity.com     |
| Phone: (703)934-2031         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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 15:28:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 15:28:04 -0700 (PDT) (envelope-from stefans@microsoft.com)
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: <0C3042E92D8A714783E2C44AB9936E1D736916@EUR-MSG-03.europe.corp.microsoft.com>
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" <stefans@microsoft.com>
To: "Steve Hanna" <steve.hanna@sun.com>, "Peter Hesse" <pmhesse@geminisecurity.com>
Cc: <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Steve Hanna
> Sent: den 22 oktober 2003 22:59
> To: Peter Hesse
> Cc: ietf-pkix@imc.org
> 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                    pmhesse@geminisecurity.com     |
> > | Phone: (703)934-2031         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: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> > On Behalf Of Santosh Chokhani
> > Sent: Wednesday, October 22, 2003 2:01 PM
> > To: ietf-pkix@imc.org
> > 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:pmhesse@geminisecurity.com]
> > Sent: Wednesday, October 22, 2003 12:59 PM
> > To: 'Santosh Chokhani'; ietf-pkix@imc.org
> > 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 13:59:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 13:59:33 -0700 (PDT) (envelope-from steve.hanna@sun.com)
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: <3F96EF91.C1E98EEF@sun.com>
Date: Wed, 22 Oct 2003 16:58:57 -0400
From: Steve Hanna <steve.hanna@sun.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Hesse <pmhesse@geminisecurity.com>
CC: ietf-pkix@imc.org
Subject: Re: AKI and SKI problem with RFC 3280?
References: <010b01c398d8$d8a5faa0$6801a8c0@gemsec.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1A4950776C601A796E2B43DF"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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                    pmhesse@geminisecurity.com     |
> | Phone: (703)934-2031         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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Santosh Chokhani
> Sent: Wednesday, October 22, 2003 2:01 PM
> To: ietf-pkix@imc.org
> 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:pmhesse@geminisecurity.com]
> Sent: Wednesday, October 22, 2003 12:59 PM
> To: 'Santosh Chokhani'; ietf-pkix@imc.org
> 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 13:30:48 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 13:30:47 -0700 (PDT) (envelope-from oelmaier@sytrust.com)
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" <oelmaier@sytrust.com>
To: "'Tom Gindin'" <tgindin@us.ibm.com>, "'Michael Myers'" <mmyers@fastq.com>
Cc: "'David Engberg'" <dave@corestreet.com>, <ietf-pkix@imc.org>
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: <OFB2CA65F3.8B7A969A-ON85256DC7.0058732C-85256DC7.0059A5C2@us.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: SyZwC6ZQgeZYSTHRvvacdQ5czZbvf20gG2XJIfB82IVL2J6CN5E9gM@t-dialin.net
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

> [...] 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 13:13:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 13:13:49 -0700 (PDT) (envelope-from pmhesse@geminisecurity.com)
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id QAA480931 for <ietf-pkix@imc.org>; Wed, 22 Oct 2003 16:13:50 -0400 (EDT)
From: "Peter Hesse" <pmhesse@geminisecurity.com>
To: <ietf-pkix@imc.org>
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$6801a8c0@gemsec.com>
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$a67f509c@hq.orionsec.com>
Importance: Normal
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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                    pmhesse@geminisecurity.com     |
| Phone: (703)934-2031         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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
On Behalf Of Santosh Chokhani
Sent: Wednesday, October 22, 2003 2:01 PM
To: ietf-pkix@imc.org
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:pmhesse@geminisecurity.com] 
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; ietf-pkix@imc.org
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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 12:46:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 12:46:01 -0700 (PDT) (envelope-from sharon.boeyen@entrust.com)
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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 15:46:16 -0400
Received: (qmail 17276 invoked by uid 111); 22 Oct 2003 23:34:58 -0000
Received: from sharon.boeyen@entrust.com 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: <9A4F653B0A375841AC75A8D17712B9C9061AC63B@sottmxs04.entrust.com>
From: Sharon Boeyen <sharon.boeyen@entrust.com>
To: "'Peter Hesse'" <pmhesse@geminisecurity.com>, "'Santosh Chokhani'" <chokhani@orionsec.com>, ietf-pkix@imc.org
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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:pmhesse@geminisecurity.com]
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; ietf-pkix@imc.org
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                    pmhesse@geminisecurity.com     |
| Phone: (703)934-2031         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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 11:01:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 11:01:37 -0700 (PDT) (envelope-from chokhani@orionsec.com)
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 14:01:31 -0400 
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 14:01:29 -0400
Message-ID: <004a01c398c6$854230c0$a67f509c@hq.orionsec.com>
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$6801a8c0@gemsec.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9MI1bI7053823
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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:pmhesse@geminisecurity.com] 
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; ietf-pkix@imc.org
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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 10:10:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 10:10:55 -0700 (PDT) (envelope-from jmdesp@free.fr)
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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 19:10:54 +0200
Message-ID: <3F96BA46.5030409@free.fr>
Date: Wed, 22 Oct 2003 19:11:34 +0200
From: Jean-Marc Desperrier <jmdesp@free.fr>
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: ietf-pkix@imc.org
Subject: Re: AKI and SKI problem with RFC 3280?
References: <003501c398a1$d0c0d1c0$6801a8c0@gemsec.com>
In-Reply-To: <003501c398a1$d0c0d1c0$6801a8c0@gemsec.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 10:08:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 10:08:55 -0700 (PDT) (envelope-from jmdesp@free.fr)
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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 19:08:54 +0200
Message-ID: <3F96B9CD.5060709@free.fr>
Date: Wed, 22 Oct 2003 19:09:33 +0200
From: Jean-Marc Desperrier <jmdesp@free.fr>
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: ietf-pkix@imc.org
Subject: Re: AKI and SKI problem with RFC 3280?
References: <003501c398a1$d0c0d1c0$6801a8c0@gemsec.com>
In-Reply-To: <003501c398a1$d0c0d1c0$6801a8c0@gemsec.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 10:00:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 10:00:32 -0700 (PDT) (envelope-from pmhesse@geminisecurity.com)
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" <pmhesse@geminisecurity.com>
To: "'Santosh Chokhani'" <chokhani@orionsec.com>, <ietf-pkix@imc.org>
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$6801a8c0@gemsec.com>
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$a67f509c@hq.orionsec.com>
Importance: Normal
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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                    pmhesse@geminisecurity.com     |
| Phone: (703)934-2031         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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 09:59:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 09:59:54 -0700 (PDT) (envelope-from maisenberg@verisign.com)
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: <6953F9859AF8BF45B04729A422640325095C2F3D@vsvapostal1.prod.netsol.com>
From: "Aisenberg, Michael" <maisenberg@verisign.com>
To: "'Anders Rundgren'" <anders.rundgren@telia.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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:	ietf-pkix@imc.org
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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 09:46:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 09:46:39 -0700 (PDT) (envelope-from mmyers@fastq.com)
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 mmyers@fastq.com)
From: "Michael Myers" <mmyers@fastq.com>
To: "Tom Gindin" <tgindin@us.ibm.com>
Cc: "David Engberg" <dave@corestreet.com>, <ietf-pkix@imc.org>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Wed, 22 Oct 2003 09:49:04 -0700
Message-ID: <EOEGJNFMMIBDKGFONJJDMEGLDFAA.mmyers@fastq.com>
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: <OFB2CA65F3.8B7A969A-ON85256DC7.0058732C-85256DC7.0059A5C2@us.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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:tgindin@us.ibm.com]
> Sent: Wednesday, October 22, 2003 9:19 AM
> To: Michael Myers
> Cc: David Engberg; ietf-pkix@imc.org
> 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 09:19:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 09:19:41 -0700 (PDT) (envelope-from tgindin@us.ibm.com)
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" <mmyers@fastq.com>
Cc: "David Engberg" <dave@corestreet.com>, ietf-pkix@imc.org
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 <tgindin@us.ibm.com>
Message-ID: <OFB2CA65F3.8B7A969A-ON85256DC7.0058732C-85256DC7.0059A5C2@us.ibm.com>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

        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" <mmyers@fastq.com>
Sent by: owner-ietf-pkix@mail.imc.org
10/18/2003 09:14 PM

 
        To:     "David Engberg" <dave@corestreet.com>
        cc:     <ietf-pkix@imc.org>
        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
(602) 739-7744







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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 08:02:48 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 08:02:47 -0700 (PDT) (envelope-from chokhani@orionsec.com)
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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 11:02:05 -0400 
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 11:02:04 -0400
Message-ID: <003901c398ad$74568fe0$a67f509c@hq.orionsec.com>
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$6801a8c0@gemsec.com>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9MF2lI7045440
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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:pmhesse@geminisecurity.com] 
Sent: Wednesday, October 22, 2003 9:39 AM
To: 'Santosh Chokhani'; ietf-pkix@imc.org
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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 06:46:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 06:46:29 -0700 (PDT) (envelope-from pmhesse@geminisecurity.com)
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" <pmhesse@geminisecurity.com>
To: "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <michael@stroeder.com>, <ietf-pkix@imc.org>
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$6801a8c0@gemsec.com>
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: <3F963CB8.7030508@stroeder.com>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9MDkUI7041407
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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                    pmhesse@geminisecurity.com     |
| Phone: (703)934-2031         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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 06:40:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 06:40:06 -0700 (PDT) (envelope-from pmhesse@geminisecurity.com)
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" <pmhesse@geminisecurity.com>
To: "'Santosh Chokhani'" <chokhani@orionsec.com>, <ietf-pkix@imc.org>
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$6801a8c0@gemsec.com>
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$9e00a8c0@hq.orionsec.com>
Importance: Normal
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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                    pmhesse@geminisecurity.com     |
| Phone: (703)934-2031         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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 06:26:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 06:26:38 -0700 (PDT) (envelope-from kent@bbn.com)
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: kent@po2.bbn.com
Message-Id: <p06002007bbbc3474b916@[128.89.89.75]>
In-Reply-To: <200310220726.h9M7QH013754@cs.auckland.ac.nz>
References: <200310220726.h9M7QH013754@cs.auckland.ac.nz>
Date: Wed, 22 Oct 2003 09:21:25 -0400
To: pgut001@cs.auckland.ac.nz (Peter Gutmann)
From: Stephen Kent <kent@bbn.com>
Subject: RE: AKI and SKI problem with RFC 3280?
Cc: aarsenau@bbn.com, ietf-pkix@imc.org, pgut001@cs.auckland.ac.nz, stefans@microsoft.com, housley@vigilsec.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

At 20:26 +1300 10/22/03, Peter Gutmann wrote:
>"Al Arsenault" <aarsenau@bbn.com> 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 06:24:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 06:23:44 -0700 (PDT) (envelope-from stefans@microsoft.com)
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: <0C3042E92D8A714783E2C44AB9936E1D6FE970@EUR-MSG-03.europe.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AKI and SKI problem with RFC 3280?
Thread-Index: AcOYeaWbTIQQjbRFSaWQfl9Q+kOxmQACiVeg
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Peter Gutmann" <pgut001@cs.auckland.ac.nz>, <aarsenau@bbn.com>, <ietf-pkix@imc.org>
Cc: <housley@vigilsec.com>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

I agree with Peter,

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

/Stefan

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Peter Gutmann
> Sent: den 22 oktober 2003 09:26
> To: aarsenau@bbn.com; ietf-pkix@imc.org; pgut001@cs.auckland.ac.nz;
Stefan
> Santesson
> Cc: housley@vigilsec.com
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> 
> "Al Arsenault" <aarsenau@bbn.com> 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 05:57:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 05:56:58 -0700 (PDT) (envelope-from kent@bbn.com)
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: kent@po2.bbn.com
Message-Id: <p06002003bbbc2da11fc1@[128.89.89.75]>
In-Reply-To: <3F963CB8.7030508@stroeder.com>
References: <200310211309.h9LD9YR08254@cs.auckland.ac.nz> <3F9540EB.E725568D@sun.com> <3F963CB8.7030508@stroeder.com>
Date: Wed, 22 Oct 2003 08:53:38 -0400
To: Michael =?iso-8859-1?Q?Str=F6der?=  <michael@stroeder.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: AKI and SKI problem with RFC 3280?
Cc: ietf-pkix@imc.org
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 05:31:10 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 05:31:08 -0700 (PDT) (envelope-from kelm@secorvo.de)
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" <kelm@secorvo.de>
Organization: Secorvo Security Consulting GmbH
To: "Anders Rundgren" <anders.rundgren@telia.com>, <ietf-pkix@imc.org>
Date: Wed, 22 Oct 2003 14:30:16 +0200
MIME-Version: 1.0
Subject: Re: The value of qualified certificates
Reply-to: kelm@secorvo.de
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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. +49 721 6105-461, Fax +49 721 6105-455
E-Mail kelm@secorvo.de, 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 05:11:48 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 05:11:47 -0700 (PDT) (envelope-from aarsenau@bbn.com)
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" <aarsenau@bbn.com>
To: "Peter Gutmann" <pgut001@cs.auckland.ac.nz>, <ietf-pkix@imc.org>, <stefans@microsoft.com>
Cc: <housley@vigilsec.com>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 08:08:29 -0400
Message-ID: <GBEOIAAPLLBIMLPDGHDHMEBACFAA.aarsenau@bbn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200310220726.h9M7QH013754@cs.auckland.ac.nz>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

Okay, now I'm *truly* confused.


-----Original Message-----
From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]
Sent: Wednesday, October 22, 2003 3:26 AM
To: aarsenau@bbn.com; ietf-pkix@imc.org; pgut001@cs.auckland.ac.nz;
stefans@microsoft.com
Cc: housley@vigilsec.com
Subject: RE: AKI and SKI problem with RFC 3280?


"Al Arsenault" <aarsenau@bbn.com> 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 03:29:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 03:29:35 -0700 (PDT) (envelope-from anders.rundgren@telia.com)
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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 12:29:33 +0200 (CEST)
Message-ID: <016d01c39887$03486970$0500a8c0@arport>
From: "Anders Rundgren" <anders.rundgren@telia.com>
To: <ietf-pkix@imc.org>
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: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 01:16:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 01:16:53 -0700 (PDT) (envelope-from michael@stroeder.com)
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id B25CD22C5F for <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 10:15:52 +0200 (CEST)
Message-ID: <3F963CB8.7030508@stroeder.com>
Date: Wed, 22 Oct 2003 10:15:52 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
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: ietf-pkix@imc.org
Subject: Re: AKI and SKI problem with RFC 3280?
References: <200310211309.h9LD9YR08254@cs.auckland.ac.nz> <3F9540EB.E725568D@sun.com>
In-Reply-To: <3F9540EB.E725568D@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 00:25:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
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 owner-ietf-pkix@mail.imc.org 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 <ietf-pkix@imc.org>; Wed, 22 Oct 2003 00:25:27 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz)
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: <200310220726.h9M7QH013754@cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: aarsenau@bbn.com, ietf-pkix@imc.org, pgut001@cs.auckland.ac.nz, stefans@microsoft.com
Subject: RE: AKI and SKI problem with RFC 3280?
Cc: housley@vigilsec.com
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

"Al Arsenault" <aarsenau@bbn.com> 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 <ietf-pkix-bks@above.proper.com>; Wed, 22 Oct 2003 00:22:42 -0700 (PDT) (envelope-from