RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

["Liaquat Khan" <[e-mail]>]

Steve,

I appreciate the difference you point out.  Although it's not a major
issue for me, I still feel that the CA may want to direct RPs to the
SCVP service it thinks is best for its certificates (whether or not the
CA operates this SCVP service).  

Furthermore, whether RPs make use of this AIA extension or not is up to
them.  This is the reality today with the use of AIA for OCSP.  Many
PKIs require their RPs to ignore this field and go to a locally
configured OCSP responder (4-corner model).  

Also even if RPs choose their own SCVP service, their may be a need to
relay the SCVP request on.  The current SCVP draft mentions server
relaying as a possibility.  The information from AIA extension could in
this instance be used to aid SCVP server relaying.

Regards,
LK 

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: 29 August 2003 02:08
To: Faisal
Cc: Denis Pinkas; [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


At 10:24 +0500 8/28/03, Faisal wrote:
>Denis,
>
>- Why is SCVP considered not part of a CA service and
>OCSP is?
>- Where is this defined?
>- Also whether the SCVP service is provided by a CA or provided by some
>other trusted third party, would it still not be a good idea for the CA
>to identify how to locate the responsible SCVP service for its
>certificates (assuming there is one)?
>- Why does it matter who is providing the service?
>
>I don't understand
>
>Regards,
>F a i s a l

OCSP is explicitly an alternative to CRLs, and CRLs are managed by 
CAs. Thus a CA issuing a cert can reasonably choose to insert a 
pointer in AIA to an OCSP server that the CA (or its designee) 
operates, just as it would have inserted a pointer to a repository 
for retrieving CRLs signed by that CA.  In contrast, the choice of an 
SCVP server is a local matter, relative to an RP, and thus it would 
generally be inappropriate for a CA to direct an RP to an SCVP server.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7U9C4gc068237 for <[e-mail]>; Sat, 30 Aug 2003 02:12:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7U9C44D068236 for ietf-pkix-bks; Sat, 30 Aug 2003 02:12:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from einsteinium.btinternet.com (einsteinium.btinternet.com [194.73.73.147]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7U9C1gc068200 for <[e-mail]>; Sat, 30 Aug 2003 02:12:02 -0700 (PDT) (envelope-from [e-mail])
Received: from host213-122-47-69.in-addr.btopenworld.com ([213.122.47.69] helo=laptoplk) by einsteinium.btinternet.com with esmtp (Exim 3.22 #23) id 19t1lz-0004vb-00; Sat, 30 Aug 2003 10:11:56 +0100
From: "Liaquat Khan" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "'Faisal'" <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Sat, 30 Aug 2003 10:04:31 +0100
Message-ID: <000401c36ed5$bacafb20$452f7ad5@laptoplk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

I appreciate the difference you point out.  Although it's not a major
issue for me, I still feel that the CA may want to direct RPs to the
SCVP service it thinks is best for its certificates (whether or not the
CA operates this SCVP service).  

Furthermore, whether RPs make use of this AIA extension or not is up to
them.  This is the reality today with the use of AIA for OCSP.  Many
PKIs require their RPs to ignore this field and go to a locally
configured OCSP responder (4-corner model).  

Also even if RPs choose their own SCVP service, their may be a need to
relay the SCVP request on.  The current SCVP draft mentions server
relaying as a possibility.  The information from AIA extension could in
this instance be used to aid SCVP server relaying.

Regards,
LK 

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: 29 August 2003 02:08
To: Faisal
Cc: Denis Pinkas; [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


At 10:24 +0500 8/28/03, Faisal wrote:
>Denis,
>
>- Why is SCVP considered not part of a CA service and
>OCSP is?
>- Where is this defined?
>- Also whether the SCVP service is provided by a CA or provided by some
>other trusted third party, would it still not be a good idea for the CA
>to identify how to locate the responsible SCVP service for its
>certificates (assuming there is one)?
>- Why does it matter who is providing the service?
>
>I don't understand
>
>Regards,
>F a i s a l

OCSP is explicitly an alternative to CRLs, and CRLs are managed by 
CAs. Thus a CA issuing a cert can reasonably choose to insert a 
pointer in AIA to an OCSP server that the CA (or its designee) 
operates, just as it would have inserted a pointer to a repository 
for retrieving CRLs signed by that CA.  In contrast, the choice of an 
SCVP server is a local matter, relative to an RP, and thus it would 
generally be inappropriate for a CA to direct an RP to an SCVP server.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TJTOgc005977 for <[e-mail]>; Fri, 29 Aug 2003 12:29:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TJTOus005976 for ietf-pkix-bks; Fri, 29 Aug 2003 12:29:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TJTMgc005970 for <[e-mail]>; Fri, 29 Aug 2003 12:29:23 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.91]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h7TJTOD46522 for <[e-mail]>; Fri, 29 Aug 2003 12:29:24 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: AIA for SCVP
Date: Fri, 29 Aug 2003 12:33:36 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If WG poll was called on the above subject, I would vote in
favor of its definition.

Michael Myers
[phone]


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Trevor Freeman
> Sent: Friday, August 29, 2003 11:14 AM
> To: Denis Pinkas
> Cc: Stephen Kent; Faisal; [e-mail]
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
> [SCVP-AIA]
>
>
>
> Denis,
> The question of what is or is not useful information
> is down to your
> point of view. Just because you don't value it, does
> not mean others
> will view it likewise.
> Trevor




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TICCgc097813 for <[e-mail]>; Fri, 29 Aug 2003 11:12:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TICCCK097812 for ietf-pkix-bks; Fri, 29 Aug 2003 11:12:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TICAgc097806 for <[e-mail]>; Fri, 29 Aug 2003 11:12:10 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Aug 2003 11:12:03 -0700
Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 29 Aug 2003 11:12:08 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Aug 2003 11:12:13 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Aug 2003 11:12:13 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Aug 2003 11:11:26 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 29 Aug 2003 11:13:38 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
thread-index: AcNuT+7o4qMNRcpKT/WFVgge23gKiQAB9V2Q
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, "Faisal" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 29 Aug 2003 18:11:26.0174 (UTC) FILETIME=[F61C67E0:01C36E58]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7TICBgc097807
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
The question of what is or is not useful information is down to your
point of view. Just because you don't value it, does not mean others
will view it likewise.
Trevor
 

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Friday, August 29, 2003 10:05 AM
To: Trevor Freeman
Cc: Stephen Kent; Faisal; [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]

Trevor,

In my reply to Faisal, there are other arguments which basically support

Steve's position. We should refrain to include "a lot of other things"
in 
public key certificates, otherwise we would open the door to a lot of 
extensions which are not directly related to CAs, like CA best partners,
low 
rates for insurances if you have a certificate from that CA, best
refinance 
conditions if you have a certificate from that CA, ...

This would look like spam.

Denis


BTW, we are awaiting your explanations (and possibly new text) about the

differences between the concept of validation policy, as included in RFC

3379, and the same wording as used in the SCVP draft.


> Steve,
> I don't see why the use of AIA is inappropriate for SCVP. It's just a
> hint like a lot of other things in certificates such as SKID. If the
> client has configured SCVP server it uses, it is free to ignore the
> information provided by the AIA, just as client with a locally
> configured OCSP server can ignore the OSCP pointer in the AIA
extension
> today.
> Trevor
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Stephen Kent
> Sent: Thursday, August 28, 2003 6:08 PM
> To: Faisal
> Cc: Denis Pinkas; [e-mail]
> Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> At 10:24 +0500 8/28/03, Faisal wrote:
> 
>>Denis,
>>
>>- Why is SCVP considered not part of a CA service and
>>OCSP is?
>>- Where is this defined?
>>- Also whether the SCVP service is provided by a CA or provided by
some
>>other trusted third party, would it still not be a good idea for the
CA
>>to identify how to locate the responsible SCVP service for its
>>certificates (assuming there is one)?
>>- Why does it matter who is providing the service?
>>
>>I don't understand
>>
>>Regards,
>>F a i s a l
> 
> 
> OCSP is explicitly an alternative to CRLs, and CRLs are managed by 
> CAs. Thus a CA issuing a cert can reasonably choose to insert a 
> pointer in AIA to an OCSP server that the CA (or its designee) 
> operates, just as it would have inserted a pointer to a repository 
> for retrieving CRLs signed by that CA.  In contrast, the choice of an 
> SCVP server is a local matter, relative to an RP, and thus it would 
> generally be inappropriate for a CA to direct an RP to an SCVP server.
> 
> Steve
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TH50gc091210 for <[e-mail]>; Fri, 29 Aug 2003 10:05:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TH506w091209 for ietf-pkix-bks; Fri, 29 Aug 2003 10:05:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TH4wgc091195 for <[e-mail]>; Fri, 29 Aug 2003 10:04:58 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA24590; Fri, 29 Aug 2003 19:10:18 +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 TAA16473; Fri, 29 Aug 2003 19:05:47 +0200
Message-ID: <[e-mail]>
Date: Fri, 29 Aug 2003 19:04:52 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: Stephen Kent <[e-mail]>, Faisal <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

In my reply to Faisal, there are other arguments which basically support 
Steve's position. We should refrain to include "a lot of other things" in 
public key certificates, otherwise we would open the door to a lot of 
extensions which are not directly related to CAs, like CA best partners, low 
rates for insurances if you have a certificate from that CA, best refinance 
conditions if you have a certificate from that CA, ...

This would look like spam.

Denis


BTW, we are awaiting your explanations (and possibly new text) about the 
differences between the concept of validation policy, as included in RFC 
3379, and the same wording as used in the SCVP draft.


> Steve,
> I don't see why the use of AIA is inappropriate for SCVP. It's just a
> hint like a lot of other things in certificates such as SKID. If the
> client has configured SCVP server it uses, it is free to ignore the
> information provided by the AIA, just as client with a locally
> configured OCSP server can ignore the OSCP pointer in the AIA extension
> today.
> Trevor
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Stephen Kent
> Sent: Thursday, August 28, 2003 6:08 PM
> To: Faisal
> Cc: Denis Pinkas; [e-mail]
> Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> At 10:24 +0500 8/28/03, Faisal wrote:
> 
>>Denis,
>>
>>- Why is SCVP considered not part of a CA service and
>>OCSP is?
>>- Where is this defined?
>>- Also whether the SCVP service is provided by a CA or provided by some
>>other trusted third party, would it still not be a good idea for the CA
>>to identify how to locate the responsible SCVP service for its
>>certificates (assuming there is one)?
>>- Why does it matter who is providing the service?
>>
>>I don't understand
>>
>>Regards,
>>F a i s a l
> 
> 
> OCSP is explicitly an alternative to CRLs, and CRLs are managed by 
> CAs. Thus a CA issuing a cert can reasonably choose to insert a 
> pointer in AIA to an OCSP server that the CA (or its designee) 
> operates, just as it would have inserted a pointer to a repository 
> for retrieving CRLs signed by that CA.  In contrast, the choice of an 
> SCVP server is a local matter, relative to an RP, and thus it would 
> generally be inappropriate for a CA to direct an RP to an SCVP server.
> 
> Steve
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGq5gc090086 for <[e-mail]>; Fri, 29 Aug 2003 09:52:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TGq5NF090085 for ietf-pkix-bks; Fri, 29 Aug 2003 09:52:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGq2gc090074 for <[e-mail]>; Fri, 29 Aug 2003 09:52:02 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Aug 2003 09:51:58 -0700
Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 29 Aug 2003 09:51:58 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Aug 2003 09:51:58 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Aug 2003 09:51:57 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Aug 2003 09:51:24 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 29 Aug 2003 09:53:13 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
thread-index: AcNt2U5VSulwqvBCRNOegTi6k8pGvQAc7pOQ
From: "Trevor Freeman" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Faisal" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 29 Aug 2003 16:51:24.0797 (UTC) FILETIME=[C8446AD0:01C36E4D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7TGq2gc090080
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,
I don't see why the use of AIA is inappropriate for SCVP. It's just a
hint like a lot of other things in certificates such as SKID. If the
client has configured SCVP server it uses, it is free to ignore the
information provided by the AIA, just as client with a locally
configured OCSP server can ignore the OSCP pointer in the AIA extension
today.
Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: Thursday, August 28, 2003 6:08 PM
To: Faisal
Cc: Denis Pinkas; [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


At 10:24 +0500 8/28/03, Faisal wrote:
>Denis,
>
>- Why is SCVP considered not part of a CA service and
>OCSP is?
>- Where is this defined?
>- Also whether the SCVP service is provided by a CA or provided by some
>other trusted third party, would it still not be a good idea for the CA
>to identify how to locate the responsible SCVP service for its
>certificates (assuming there is one)?
>- Why does it matter who is providing the service?
>
>I don't understand
>
>Regards,
>F a i s a l

OCSP is explicitly an alternative to CRLs, and CRLs are managed by 
CAs. Thus a CA issuing a cert can reasonably choose to insert a 
pointer in AIA to an OCSP server that the CA (or its designee) 
operates, just as it would have inserted a pointer to a repository 
for retrieving CRLs signed by that CA.  In contrast, the choice of an 
SCVP server is a local matter, relative to an RP, and thus it would 
generally be inappropriate for a CA to direct an RP to an SCVP server.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7T2Wegc012001 for <[e-mail]>; Thu, 28 Aug 2003 19:32:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7T2WeGg012000 for ietf-pkix-bks; Thu, 28 Aug 2003 19:32:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7T2Wdgc011995 for <[e-mail]>; Thu, 28 Aug 2003 19:32:39 -0700 (PDT) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Aug 2003 19:32:19 -0700
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Aug 2003 19:30:14 -0700
Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Aug 2003 19:30:12 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 28 Aug 2003 19:30:11 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Aug 2003 19:30:23 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Aug 2003 19:30:12 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.150 157.54.0.150 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.150 157.54.0.150 from 157.54.1.70 157.54.1.70 via HTTP with MS-WebStorage 6.5.6944
Mime-Version: 1.0
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <p05210601bb74568e9933@[10.1.71.45]>
References:  <[e-mail] dev.microsoft.com>, <p05210601bb74568e9933@[10.1.71.45]>
To: Stephen Kent <[e-mail]>
Cc: "Terwilliger, Ann" <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
Thread-Index: AcNt1Xpu64el8/lsQmqu5S5+YMOQWg==
Message-ID: <A883CA84-4DEC-4FF7-A4A4-9726EAFBAAB9@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Thu, 28 Aug 2003 19:30:14 -0700
X-OriginalArrivalTime: 29 Aug 2003 02:30:12.0555 (UTC) FILETIME=[793601B0:01C36DD5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_D1D13840-6759-4970-A979-72F49D944E22_"

--_D1D13840-6759-4970-A979-72F49D944E22_
Content-Type: text/plain;
	charset="iso-8859-1";
	format=flowed
Content-Transfer-Encoding: quoted-printable

Depends on your definition Steve :)

We have run the latest NIST conformance tests and with very few exceptions =
(namely things we didn't implement because it was ambiguous or not practica=
l) we pass, I know this doesn't exactly mean we are conformant with 3280 bu=
t its the most complete test of that I am aware of :)

As for the specifics on name vs. key based chaining, the algorithm describe=
d in 3280 section 6.1 effectively through out valid chains as a policy if t=
he name does not match.  Its basically the last check, we know the chain cr=
yptographically validates, we know the policy intersections and are happy w=
ith them, we know and trust the issuer and despite all of this  (and a bunc=
h of other things) it says lets throughs it out anyways.

Now if key id's are not available CryptoAPI does fall back name based chain=
ing, and the "desired result" of throwing out chains that are OK with the e=
xception of name matches happens as a side effect.

So in that regard yes we are not conformant but,  I am actually quite pleas=
ed with the overall "3280" conformance of the Server 2003 chaining engine, =
in-fact we have back-ported it for XPSP2, and 2KSP5 (the next service packs=
 for these OS's).

Ryan M. Hurst


From: Stephen Kent
Sent: Thu 8/28/2003 6:02 PM
To: Ryan M. Hurst
Cc: Terwilliger, Ann; [e-mail]
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID ma=
tching)


At 15:22 -0700 8/27/03, Ryan M. Hurst wrote:
>As a point of reference CryptoAPI (and as a result Windows) performs key
>based chaining and only falls back to name based chaining if AKIs are
>not available.
>
>Ryan
>

So, you are saying that it does not conform to 3280, right?

Steve

--_D1D13840-6759-4970-A979-72F49D944E22_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText60550 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Depends on your =
definition Steve :)</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>We have run the latest NIST conf=
ormance tests and with very few exceptions (namely things we didn't impleme=
nt because it was ambiguous or not practical) we pass, I know this doesn't =
exactly mean we are conformant with 3280 but its the most complete test of =
that I am aware of :)</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>As for the specifics on name vs.=
 key based chaining, the algorithm described in 3280 section 6.1 effectivel=
y through out valid chains as a policy if the name does not match.&nbsp;&nb=
sp;Its basically the last check, we know the chain cryptographically valida=
tes, we know the policy intersections and are happy with them, we know and =
trust the issuer&nbsp;and despite all of this&nbsp; (and a bunch of other t=
hings) it says lets throughs it out anyways.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Now if key id's are not availabl=
e&nbsp;CryptoAPI does fall back name based chaining, and the "desired resul=
t" of throwing out chains that are OK with the exception of name matches ha=
ppens as a side effect.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>So in that regard yes we are not=
 conformant&nbsp;but, &nbsp;I am actually quite pleased with the overall "3=
280" conformance of the Server 2003 chaining engine, in-fact we have back-p=
orted it for XPSP2, and 2KSP5 (the next service packs for these OS's).</FON=
T></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan M. Hurst</FONT><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Stephen Kent<BR><B>Sent:</B> Thu =
8/28/2003 6:02 PM<BR><B>To:</B> Ryan M. Hurst<BR><B>Cc:</B> Terwilliger, An=
n; [e-mail]<BR><B>Subject:</B> RE: Making more of Key IDs (was RE:=
 3280 Question WRT SKID/AKID matching)<BR></FONT><BR></DIV></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">At 15:22 -0700 8/27/03, Ryan M. H=
urst wrote:
&gt;As a point of reference CryptoAPI (and as a result Windows) performs ke=
y
&gt;based chaining and only falls back to name based chaining if AKIs are
&gt;not available.
&gt;
&gt;Ryan
&gt;

So, you are saying that it does not conform to 3280, right?

Steve
</PRE></DIV></BODY></HTML>

--_D1D13840-6759-4970-A979-72F49D944E22_--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7T1Hqgc009647 for <[e-mail]>; Thu, 28 Aug 2003 18:17:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7T1HqZM009646 for ietf-pkix-bks; Thu, 28 Aug 2003 18:17:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7T1Hogc009640 for <[e-mail]>; Thu, 28 Aug 2003 18:17:51 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.1.71.45] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7T1Gwju013940; Thu, 28 Aug 2003 21:17:06 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210602bb745703b4bd@[10.1.71.45]>
In-Reply-To: <001601c36d24$a46b1fc0$[e-mail]>
References: <[e-mail]> <003c01c3618f$82676e60$[e-mail]> <[e-mail]> <001601c36d24$a46b1fc0$[e-mail]>
Date: Thu, 28 Aug 2003 21:07:36 -0400
To: "Faisal" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:24 +0500 8/28/03, Faisal wrote:
>Denis,
>
>- Why is SCVP considered not part of a CA service and
>OCSP is?
>- Where is this defined?
>- Also whether the SCVP service is provided by a CA or provided by some
>other trusted third party, would it still not be a good idea for the CA
>to identify how to locate the responsible SCVP service for its
>certificates (assuming there is one)?
>- Why does it matter who is providing the service?
>
>I don't understand
>
>Regards,
>F a i s a l

OCSP is explicitly an alternative to CRLs, and CRLs are managed by 
CAs. Thus a CA issuing a cert can reasonably choose to insert a 
pointer in AIA to an OCSP server that the CA (or its designee) 
operates, just as it would have inserted a pointer to a repository 
for retrieving CRLs signed by that CA.  In contrast, the choice of an 
SCVP server is a local matter, relative to an RP, and thus it would 
generally be inappropriate for a CA to direct an RP to an SCVP server.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7T1H9gc009627 for <[e-mail]>; Thu, 28 Aug 2003 18:17:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7T1H9N4009626 for ietf-pkix-bks; Thu, 28 Aug 2003 18:17:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7T1H8gc009617 for <[e-mail]>; Thu, 28 Aug 2003 18:17:08 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.1.71.45] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7T1Gwjs013940; Thu, 28 Aug 2003 21:17:04 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210601bb74568e9933@[10.1.71.45]>
In-Reply-To:  <[e-mail] dev.microsoft.com>
References:  <[e-mail] dev.microsoft.com>
Date: Thu, 28 Aug 2003 21:02:36 -0400
To: "Ryan M. Hurst" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
Cc: "Terwilliger, Ann" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 15:22 -0700 8/27/03, Ryan M. Hurst wrote:
>As a point of reference CryptoAPI (and as a result Windows) performs key
>based chaining and only falls back to name based chaining if AKIs are
>not available.
>
>Ryan
>

So, you are saying that it does not conform to 3280, right?

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S9Yugc040914 for <[e-mail]>; Thu, 28 Aug 2003 02:34:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7S9YuUo040913 for ietf-pkix-bks; Thu, 28 Aug 2003 02:34:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S9Ysgc040907 for <[e-mail]>; Thu, 28 Aug 2003 02:34:55 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA22752; Thu, 28 Aug 2003 11:40:13 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA17091; Thu, 28 Aug 2003 11:35:41 +0200
Message-ID: <[e-mail]>
Date: Thu, 28 Aug 2003 11:34:48 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Faisal <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
References: <[e-mail]> <003c01c3618f$82676e60$[e-mail]> <[e-mail]> <001601c36d24$a46b1fc0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Faisal,

> Denis,
> 
> - Why is SCVP considered not part of a CA service and
> OCSP is?
> - Where is this defined?
> - Also whether the SCVP service is provided by a CA or provided by some
> other trusted third party, would it still not be a good idea for the CA
> to identify how to locate the responsible SCVP service for its
> certificates (assuming there is one)?
> - Why does it matter who is providing the service?
> 
> I don't understand

An SCVP service can be provided by anybody. It is able to verify 
certificates according to one or several validation policies.

RFC 3280 states :

    Message formats and protocols supporting on-line revocation notification
    are defined in other PKIX specifications.

SCVP does not replace CRLs or OCSP.

SCVP is not simply an on-line revocation notification service, since it does 
more: path construction and revocation validation checking for all the CA 
certificates from the path up to one or more trust points.

Using an extension to indicate the location of a SCVP service would be a 
pointer to a "useful" service in the same way like a CA could indicate the 
location of useful Time-Stamping Units (TSUs). So, if we accept this 
extension, we will have to accept pointers to TSUs and in the future 
pointers to some other "useful" services like an *electronic* signature 
validation service, and maybe more.

Either we open the door to "useful" services like SCVP, or we don't.
I wonder whether we should open that door.

Denis

> Regards,
> F a i s a l
> 
> 
> ----- Original Message -----
> From: "Denis Pinkas" <[e-mail]>
> To: "Faisal" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, August 27, 2003 6:39 PM
> Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> 
>>Faisal,
>>
>>
>>>Hi,
>>
>>>    In X509Certificate, there is extension which guides us about ocsp
>>>server. I request to write a draft for scvp-aia-extension for future
>>
> support
> 
>>>of SCVP in X509Certificate.
>>
>>I do not think it would be a good idea, since an SCVP service is not part
> 
> of
> 
>>CA services. An OCSP service on the contrary is, and this is why this is
>>supported in a certificate extension.
>>
>>Denis
>>
>>
>>
>>>Kind Regards,
>>>Faisal
>>>
>>>----- Original Message -----
>>>From: <[e-mail]>
>>>To: <IETF-Announce:>
>>>Cc: <[e-mail]>
>>>Sent: Monday, August 04, 2003 7:14 PM
>>>Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt
>>>
>>>
>>>
>>>
>>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>>
>>>directories.
>>>
>>>
>>>>Title : AIA Access Method for XKMS Services
>>>>Author(s) : A. Deacon
>>>>Filename : draft-deacon-xkms-aia-00.txt
>>>>Pages : 5
>>>>Date : 2003-8-4
>>>>
>>>>Authority Information Access extension that is used to indicate how
>>>>to access CA information and services for the issuer of the
>>>>certificate in which this extension appears.  This document defines
>>>>an access method identifier that indicates the location of XKMS
>>>>[XKMS] services.
>>>>
>>>>A URL for this Internet-Draft is:
>>>>http://www.ietf.org/internet-drafts/draft-deacon-xkms-aia-00.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-deacon-xkms-aia-00.txt".
>>>>
>>>>A list of Internet-Drafts directories can be found in
>>>>http://www.ietf.org/shadow.html
>>>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>
>>>>
>>>>Internet-Drafts can also be obtained by e-mail.
>>>>
>>>>Send a message to:
>>>>[e-mail].
>>>>In the body type:
>>>>"FILE /internet-drafts/draft-deacon-xkms-aia-00.txt".
>>>>
>>>>NOTE: The mail server at ietf.org can return the document in
>>>>MIME-encoded form by using the "mpack" utility.  To use this
>>>>feature, insert the command "ENCODING mime" before the "FILE"
>>>>command.  To decode the response(s), you will need "munpack" or
>>>>a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>>>exhibit different behavior, especially when dealing with
>>>>"multipart" MIME messages (i.e. documents which have been split
>>>>up into multiple messages), so check your local documentation on
>>>>how to manipulate these messages.
>>>>
>>>>
>>>>Below is the data which will enable a MIME compliant mail reader
>>>>implementation to automatically retrieve the ASCII version of the
>>>>Internet-Draft.
>>>>
>>>
>>>
>>
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S5MRgc002827 for <[e-mail]>; Wed, 27 Aug 2003 22:22:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7S5MRY0002826 for ietf-pkix-bks; Wed, 27 Aug 2003 22:22:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7S5MPgc002817 for <[e-mail]>; Wed, 27 Aug 2003 22:22:26 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.197.10]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id h7S5KKq8017580; Thu, 28 Aug 2003 10:20:22 +0500 (GMT)
Message-ID: <001601c36d24$a46b1fc0$[e-mail]>
From: "Faisal" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <003c01c3618f$82676e60$[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Thu, 28 Aug 2003 10:24:14 +0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

- Why is SCVP considered not part of a CA service and
OCSP is?
- Where is this defined?
- Also whether the SCVP service is provided by a CA or provided by some
other trusted third party, would it still not be a good idea for the CA
to identify how to locate the responsible SCVP service for its
certificates (assuming there is one)?
- Why does it matter who is providing the service?

I don't understand

Regards,
F a i s a l


----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "Faisal" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, August 27, 2003 6:39 PM
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


>
> Faisal,
>
> > Hi,
>
> >     In X509Certificate, there is extension which guides us about ocsp
> > server. I request to write a draft for scvp-aia-extension for future
support
> > of SCVP in X509Certificate.
>
> I do not think it would be a good idea, since an SCVP service is not part
of
> CA services. An OCSP service on the contrary is, and this is why this is
> supported in a certificate extension.
>
> Denis
>
>
> > Kind Regards,
> > Faisal
> >
> > ----- Original Message -----
> > From: <[e-mail]>
> > To: <IETF-Announce:>
> > Cc: <[e-mail]>
> > Sent: Monday, August 04, 2003 7:14 PM
> > Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt
> >
> >
> >
> >>A New Internet-Draft is available from the on-line Internet-Drafts
> >
> > directories.
> >
> >>
> >>Title : AIA Access Method for XKMS Services
> >>Author(s) : A. Deacon
> >>Filename : draft-deacon-xkms-aia-00.txt
> >>Pages : 5
> >>Date : 2003-8-4
> >>
> >>Authority Information Access extension that is used to indicate how
> >>to access CA information and services for the issuer of the
> >>certificate in which this extension appears.  This document defines
> >>an access method identifier that indicates the location of XKMS
> >>[XKMS] services.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-deacon-xkms-aia-00.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-deacon-xkms-aia-00.txt".
> >>
> >>A list of Internet-Drafts directories can be found in
> >>http://www.ietf.org/shadow.html
> >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >>
> >>Internet-Drafts can also be obtained by e-mail.
> >>
> >>Send a message to:
> >>[e-mail].
> >>In the body type:
> >>"FILE /internet-drafts/draft-deacon-xkms-aia-00.txt".
> >>
> >>NOTE: The mail server at ietf.org can return the document in
> >>MIME-encoded form by using the "mpack" utility.  To use this
> >>feature, insert the command "ENCODING mime" before the "FILE"
> >>command.  To decode the response(s), you will need "munpack" or
> >>a MIME-compliant mail reader.  Different MIME-compliant mail readers
> >>exhibit different behavior, especially when dealing with
> >>"multipart" MIME messages (i.e. documents which have been split
> >>up into multiple messages), so check your local documentation on
> >>how to manipulate these messages.
> >>
> >>
> >>Below is the data which will enable a MIME compliant mail reader
> >>implementation to automatically retrieve the ASCII version of the
> >>Internet-Draft.
> >>
> >
> >
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RMMsgc088821 for <[e-mail]>; Wed, 27 Aug 2003 15:22:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RMMsrv088820 for ietf-pkix-bks; Wed, 27 Aug 2003 15:22:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RMMrgc088811 for <[e-mail]>; Wed, 27 Aug 2003 15:22:53 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Aug 2003 15:22:53 -0700
Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Aug 2003 15:22:50 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Aug 2003 15:22:49 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Aug 2003 15:23:05 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Aug 2003 15:22:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
Date: Wed, 27 Aug 2003 15:22:43 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
thread-index: AcNs4rSjE24JE5DzRai5rkIXXhPAiwABuO6Q
From: "Ryan M. Hurst" <[e-mail]>
To: "Terwilliger, Ann" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Aug 2003 22:22:33.0809 (UTC) FILETIME=[B64B8C10:01C36CE9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7RMMrgc088814
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As a point of reference CryptoAPI (and as a result Windows) performs key
based chaining and only falls back to name based chaining if AKIs are
not available.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Terwilliger, Ann
Sent: Wednesday, August 27, 2003 11:26 AM
To: [e-mail]
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID
matching)


I agree that trust path construction should be done with DNs rather than
Key Ids.  However, on occasion we have needed to have more than one CA
certificate with the exact same DN in our private hierarchy.  In that
case, trust path construction requires that there be a way to ensure
that we have the correct certificates to validate the signatures in the
chain.  In general we either use the key ids (AKID/SKID) or (gasp) the
other parameters included in the AKI extension--authorityCertIssuer and
authorityCertSerialNumber.  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, August 22, 2003 7:59 AM
Cc: [e-mail]
Subject: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID
matching)





Donning flameproof underpants for this one.

Trust path construction should be done with Distinguished Names
rather than Key IDs but I feel that, with a bit of work, Key IDs could
be made into a reliable mechanism and one that would permit
local trust path construction in the continuing absence of a public
global
directory. It requires that the Key IDs can only be generated at the
same
time as, and by the same device as, the keys themselves. RFC3280 states
that a Key ID need only be generated if there is not one already present
and merely copied when present. Employing this method would mask out
local differences in the interpretations of Key ID algorithms. If the
value
of the keys can be relied on then so can the trust paths that can be
built
using them.

Toast ?

Chris






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RL64gc085422 for <[e-mail]>; Wed, 27 Aug 2003 14:06:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RL64ux085421 for ietf-pkix-bks; Wed, 27 Aug 2003 14:06:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stpmx.guidant.com (stpmx.guidant.com [132.189.76.11]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RL5xgc085413 for <[e-mail]>; Wed, 27 Aug 2003 14:06:02 -0700 (PDT) (envelope-from [e-mail])
Received: from stpvsc01.stp.guidant.com ([132.189.8.65]) by stpmx.guidant.com (8.12.8p1/8.12.8) with SMTP id h7RL63d4009373; Wed, 27 Aug 2003 16:06:03 -0500 (CDT)
Received: from stpmse01.ad.guidant.com ([132.189.8.148]) by stpmse01.ad.guidant.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Aug 2003 15:54:59 -0500
Received: from stpmse03.ad.guidant.com ([132.189.8.133]) by stpmse01.ad.guidant.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Aug 2003 15:54:59 -0500
Received: from mail pickup service by stpmse03.ad.guidant.com with Microsoft SMTPSVC; Wed, 27 Aug 2003 15:54:58 -0500
Received: from stpmse01.ad.guidant.com ([132.189.8.30]) by stpmse03.ad.guidant.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Aug 2003 12:55:06 -0500
Received: from stpvsc01.stp.guidant.com ([132.189.8.65]) by stpmse01.ad.guidant.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Aug 2003 12:00:29 -0500
Received: from guidant.com (temasp01 [192.168.116.5]) by temmx.guidant.com (8.12.8p1/8.12.8) with ESMTP id h7RGmcPU027050 for <[e-mail]>; Wed, 27 Aug 2003 09:49:04 -0700 (PDT)
Received: from ([208.184.76.39]) by temasp01.guidant.com with ESMTP with TLS; Wed, 27 Aug 2003 09:59:12 -0700 (PDT)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RG8ggc073469 for <[e-mail]>; Wed, 27 Aug 2003 09:08:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RG8ga8073468 for ietf-pkix-bks; Wed, 27 Aug 2003 09:08:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.datapower.com (ip67-93-141-188.z141-93-67.customer.algx.net [67.93.141.188]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RG8dgc073461 for <[e-mail]>; Wed, 27 Aug 2003 09:08:40 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 13812 invoked by uid 505); 27 Aug 2003 16:08:40 -0000
Received: from [e-mail] by smtp.datapower.com by uid 502 with qmail-scanner-1.14  (clamscan: 0.51. spamassassin: 2.42.  Clear:.  Processed in 1.300827 secs); 27 Aug 2003 16:08:40 -0000
Received: from ip67-93-141-189.z141-93-67.customer.algx.net (HELO datapower.com) (67.93.141.189) by ip67-93-141-188.z141-93-67.customer.algx.net with SMTP; 27 Aug 2003 16:08:39 -0000
Message-ID: <[e-mail]>
Date: Wed, 27 Aug 2003 12:08:38 -0400
From: Rich Salz <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Deacon, Alex" <[e-mail]>
CC: "'Ryan M. Hurst'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 27 Aug 2003 17:00:29.0850 (UTC) FILETIME=[B85167A0:01C36CBC]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Specify XKMS over SOAP.
> Clarify and rename the OID to specify XKMS-Validate only.

Great.

> Make support for X509Certificate a MUST.  As an alternative I also like 
> X509IssuerSerial as a MUST as it makes requests smaller which is nice in 
> some mobile environments.  As for X509Data, I suppose supporting this 
> makes sense if we want to allow a single request to contain more then 1 
> cert.  (I.e. please validate these 12 certs).  My inclination is to keep 
> things simple and not allow this in this profile, especially since XKMS 
> validates the whole chain, not just a single cert.  But to be honest I 
> don't have a strong opinion so let me know what you think.

I don't have a problem with IssuerSerial as a MUST, since it's a fairly 
short step to go from that to OCSP certid. :)  But if others want to see 
it a SHOULD, that's okay.

I would put X509Data as a MAY, for just the same reasons you suggest.

> Borrow the OCSP trust model where responses can be CA signed, CA 
> delegated or trusted via some out of band mechanism (other).

Good.  Perhaps can even cut down on the words you ahve to write and 
mainly incorporate by reference.
	/r$



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RJjlgc082311 for <[e-mail]>; Wed, 27 Aug 2003 12:45:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RJjlWN082310 for ietf-pkix-bks; Wed, 27 Aug 2003 12:45:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RJjigc082300 for <[e-mail]>; Wed, 27 Aug 2003 12:45:45 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id PAA448113; Wed, 27 Aug 2003 15:45:32 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "'Terwilliger, Ann'" <[e-mail]>, <[e-mail]>
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
Date: Wed, 27 Aug 2003 15:44:54 -0400
Organization: Gemini Security Solutions, Inc.
Message-ID: <000701c36cd3$b6b60fb0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ann,

You bring up an interesting point that I'd like to note to implementers.
authorityCertIssuer and authorityCertSerialNumber cannot be used as a
matching rule for path building in a mesh environment.  What I mean by
"matching rule" is that it can't be used to truly exclude certificates
from consideration when building a path.  (It can be used as a sorting
criteria, but may not be a good one for the reasons below)

Assume that a CA, called CA1, has two certificates; one from its domain
issuer and one from another issuer (in a different domain).  When it
builds and signs certificates, it has to choose a serial number to put
into the AKIDs of these certificates, from one of the two certificates
it has been issued.  Just because the serial number points to one of
CA1's issuers does not mean that paths that go through the other
issuer(s) are not valid.

It may be easier to see a picture, so let me refer you to slide 26 of
this briefing:
http://csrc.ncsl.nist.gov/pki/twg/y2000/presentations/twg-00-13.pdf

--Peter

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


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Terwilliger, Ann
Sent: Wednesday, August 27, 2003 2:26 PM
To: [e-mail]
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID
matching)



I agree that trust path construction should be done with DNs rather than
Key Ids.  However, on occasion we have needed to have more than one CA
certificate with the exact same DN in our private hierarchy.  In that
case, trust path construction requires that there be a way to ensure
that we have the correct certificates to validate the signatures in the
chain.  In general we either use the key ids (AKID/SKID) or (gasp) the
other parameters included in the AKI extension--authorityCertIssuer and
authorityCertSerialNumber.  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, August 22, 2003 7:59 AM
Cc: [e-mail]
Subject: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID
matching)





Donning flameproof underpants for this one.

Trust path construction should be done with Distinguished Names rather
than Key IDs but I feel that, with a bit of work, Key IDs could be made
into a reliable mechanism and one that would permit local trust path
construction in the continuing absence of a public global directory. It
requires that the Key IDs can only be generated at the same time as, and
by the same device as, the keys themselves. RFC3280 states that a Key ID
need only be generated if there is not one already present and merely
copied when present. Employing this method would mask out local
differences in the interpretations of Key ID algorithms. If the value of
the keys can be relied on then so can the trust paths that can be built
using them.

Toast ?

Chris



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RJ4Pgc080476 for <[e-mail]>; Wed, 27 Aug 2003 12:04:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RJ4PO7080475 for ietf-pkix-bks; Wed, 27 Aug 2003 12:04:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RJ4Ogc080467 for <[e-mail]>; Wed, 27 Aug 2003 12:04:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7RJ4Hjm009779; Wed, 27 Aug 2003 15:04:18 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210613bb72afb08e39@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 27 Aug 2003 15:04:11 -0400
To: "Terwilliger, Ann" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID m atching)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:25 -0700 8/27/03, Terwilliger, Ann wrote:
>I agree that trust path construction should be done with DNs rather 
>than Key Ids.  However, on occasion we have needed to have more than 
>one CA certificate with the exact same DN in our private hierarchy. 
>In that case, trust path construction requires that there be a way 
>to ensure that we have the correct certificates to validate the 
>signatures in the chain.  In general we either use the key ids 
>(AKID/SKID) or (gasp) the other parameters included in the AKI 
>extension--authorityCertIssuer and authorityCertSerialNumber.

Ann,

Nothing wrong with that. The whole purpose of the key ID construct is 
to allow one to locate the right cert, in an efficient manner, among 
a set of certs for the same CA, at least with regard to cert chain 
processing. So the notion is that one locates the right CA using the 
issuer name, then uses the key ID to find the right cert for that CA 
(e.g., in a directory). But, given that you selected the right CA 
cert as described here, you can check the path using just comparing 
issuer & subject names.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RIS9gc079371 for <[e-mail]>; Wed, 27 Aug 2003 11:28:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RIS9U5079370 for ietf-pkix-bks; Wed, 27 Aug 2003 11:28:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from visa.com (portal3.visa.com [198.80.42.3]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RIS8gc079362 for <[e-mail]>; Wed, 27 Aug 2003 11:28:08 -0700 (PDT) (envelope-from [e-mail])
Received: from ([10.72.11.168]) by portal3.visa.com with ESMTP ; Wed, 27 Aug 2003 11:25:36 -0700 (PDT)
Received: by sw720x001.visa.com with Internet Mail Service (5.5.2653.19) id <RH53HC8Y>; Wed, 27 Aug 2003 11:25:44 -0700
Message-ID: <[e-mail]>
From: "Terwilliger, Ann" <[e-mail]>
To: [e-mail]
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID m atching)
Date: Wed, 27 Aug 2003 11:25:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that trust path construction should be done with DNs rather than Key Ids.  However, on occasion we have needed to have more than one CA certificate with the exact same DN in our private hierarchy.  In that case, trust path construction requires that there be a way to ensure that we have the correct certificates to validate the signatures in the chain.  In general we either use the key ids (AKID/SKID) or (gasp) the other parameters included in the AKI extension--authorityCertIssuer and authorityCertSerialNumber.  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, August 22, 2003 7:59 AM
Cc: [e-mail]
Subject: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID
matching)





Donning flameproof underpants for this one.

Trust path construction should be done with Distinguished Names
rather than Key IDs but I feel that, with a bit of work, Key IDs could
be made into a reliable mechanism and one that would permit
local trust path construction in the continuing absence of a public global
directory. It requires that the Key IDs can only be generated at the same
time as, and by the same device as, the keys themselves. RFC3280 states
that a Key ID need only be generated if there is not one already present
and merely copied when present. Employing this method would mask out
local differences in the interpretations of Key ID algorithms. If the value
of the keys can be relied on then so can the trust paths that can be built
using them.

Toast ?

Chris



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RG8ggc073469 for <[e-mail]>; Wed, 27 Aug 2003 09:08:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RG8ga8073468 for ietf-pkix-bks; Wed, 27 Aug 2003 09:08:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.datapower.com (ip67-93-141-188.z141-93-67.customer.algx.net [67.93.141.188]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RG8dgc073461 for <[e-mail]>; Wed, 27 Aug 2003 09:08:40 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 13812 invoked by uid 505); 27 Aug 2003 16:08:40 -0000
Received: from [e-mail] by smtp.datapower.com by uid 502 with qmail-scanner-1.14  (clamscan: 0.51. spamassassin: 2.42.  Clear:.  Processed in 1.300827 secs); 27 Aug 2003 16:08:40 -0000
Received: from ip67-93-141-189.z141-93-67.customer.algx.net (HELO datapower.com) (67.93.141.189) by ip67-93-141-188.z141-93-67.customer.algx.net with SMTP; 27 Aug 2003 16:08:39 -0000
Message-ID: <[e-mail]>
Date: Wed, 27 Aug 2003 12:08:38 -0400
From: Rich Salz <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Deacon, Alex" <[e-mail]>
CC: "'Ryan M. Hurst'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Specify XKMS over SOAP.
> Clarify and rename the OID to specify XKMS-Validate only.

Great.

> Make support for X509Certificate a MUST.  As an alternative I also like 
> X509IssuerSerial as a MUST as it makes requests smaller which is nice in 
> some mobile environments.  As for X509Data, I suppose supporting this 
> makes sense if we want to allow a single request to contain more then 1 
> cert.  (I.e. please validate these 12 certs).  My inclination is to keep 
> things simple and not allow this in this profile, especially since XKMS 
> validates the whole chain, not just a single cert.  But to be honest I 
> don't have a strong opinion so let me know what you think.

I don't have a problem with IssuerSerial as a MUST, since it's a fairly 
short step to go from that to OCSP certid. :)  But if others want to see 
it a SHOULD, that's okay.

I would put X509Data as a MAY, for just the same reasons you suggest.

> Borrow the OCSP trust model where responses can be CA signed, CA 
> delegated or trusted via some out of band mechanism (other).

Good.  Perhaps can even cut down on the words you ahve to write and 
mainly incorporate by reference.
	/r$



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RFJRgc071030 for <[e-mail]>; Wed, 27 Aug 2003 08:19:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RFJRH4071029 for ietf-pkix-bks; Wed, 27 Aug 2003 08:19:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RFJQgc071016 for <[e-mail]>; Wed, 27 Aug 2003 08:19:26 -0700 (PDT)
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 51F97206609 for <[e-mail]>; Wed, 27 Aug 2003 11:17:50 -0400 (EDT)
Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19s1Q7-0005w3-Ok for [e-mail]; Wed, 27 Aug 2003 10:37:11 -0400
Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19s1Gq-0005VK-J6 for [e-mail]; Wed, 27 Aug 2003 10:27:36 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01750; Wed, 27 Aug 2003 10:27:31 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-08.txt
Date: Wed, 27 Aug 2003 10:27:30 -0400
MIME-Version: 1.0
Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+130191_9175328456492_64141861768"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--MIMEStream=_0+130191_9175328456492_64141861768

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 Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-08.txt
	Pages		: 45
	Date		: 2003-8-27
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 Public Key Infrastructure (PKI) certificates as 
defined in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is derived from, 
and signed by, a normal X.509 Public Key End Entity Certificate or 
by another Proxy Certificate for the purpose of providing 
restricted proxying and delegation within a PKI based 
authentication system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-08.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-proxy-08.txt".

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-proxy-08.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.

--MIMEStream=_0+130191_9175328456492_64141861768
Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+96985_284003144813390_0244957593"


--MIMEStream=_1+96985_284003144813390_0244957593
Content-Type: Message/External-body; access-type="mail-server"; server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-proxy-08.txt

--MIMEStream=_1+96985_284003144813390_0244957593
Content-Type: Message/External-body; name="draft-ietf-pkix-proxy-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"

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

--MIMEStream=_1+96985_284003144813390_0244957593--
--MIMEStream=_0+130191_9175328456492_64141861768--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RERZgc068787 for <[e-mail]>; Wed, 27 Aug 2003 07:27:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RERZg6068786 for ietf-pkix-bks; Wed, 27 Aug 2003 07:27:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RERYgc068781 for <[e-mail]>; Wed, 27 Aug 2003 07:27:34 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01750; Wed, 27 Aug 2003 10:27:31 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-08.txt
Date: Wed, 27 Aug 2003 10:27:30 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-08.txt
	Pages		: 45
	Date		: 2003-8-27
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 Public Key Infrastructure (PKI) certificates as 
defined in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is derived from, 
and signed by, a normal X.509 Public Key End Entity Certificate or 
by another Proxy Certificate for the purpose of providing 
restricted proxying and delegation within a PKI based 
authentication system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-08.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-proxy-08.txt".

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-proxy-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-proxy-08.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RDdDgc066969 for <[e-mail]>; Wed, 27 Aug 2003 06:39:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RDdDQl066968 for ietf-pkix-bks; Wed, 27 Aug 2003 06:39:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RDdAgc066961 for <[e-mail]>; Wed, 27 Aug 2003 06:39:10 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA29976; Wed, 27 Aug 2003 15:44:26 +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 PAA09434; Wed, 27 Aug 2003 15:39:59 +0200
Message-ID: <[e-mail]>
Date: Wed, 27 Aug 2003 15:39:06 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Faisal <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
References: <[e-mail]> <003c01c3618f$82676e60$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Faisal,

> Hi,

>     In X509Certificate, there is extension which guides us about ocsp
> server. I request to write a draft for scvp-aia-extension for future support
> of SCVP in X509Certificate.

I do not think it would be a good idea, since an SCVP service is not part of 
CA services. An OCSP service on the contrary is, and this is why this is 
supported in a certificate extension.

Denis


> Kind Regards,
> Faisal
> 
> ----- Original Message -----
> From: <[e-mail]>
> To: <IETF-Announce:>
> Cc: <[e-mail]>
> Sent: Monday, August 04, 2003 7:14 PM
> Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt
> 
> 
> 
>>A New Internet-Draft is available from the on-line Internet-Drafts
> 
> directories.
> 
>>
>>Title : AIA Access Method for XKMS Services
>>Author(s) : A. Deacon
>>Filename : draft-deacon-xkms-aia-00.txt
>>Pages : 5
>>Date : 2003-8-4
>>
>>Authority Information Access extension that is used to indicate how
>>to access CA information and services for the issuer of the
>>certificate in which this extension appears.  This document defines
>>an access method identifier that indicates the location of XKMS
>>[XKMS] services.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-deacon-xkms-aia-00.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-deacon-xkms-aia-00.txt".
>>
>>A list of Internet-Drafts directories can be found in
>>http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>[e-mail].
>>In the body type:
>>"FILE /internet-drafts/draft-deacon-xkms-aia-00.txt".
>>
>>NOTE: The mail server at ietf.org can return the document in
>>MIME-encoded form by using the "mpack" utility.  To use this
>>feature, insert the command "ENCODING mime" before the "FILE"
>>command.  To decode the response(s), you will need "munpack" or
>>a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>exhibit different behavior, especially when dealing with
>>"multipart" MIME messages (i.e. documents which have been split
>>up into multiple messages), so check your local documentation on
>>how to manipulate these messages.
>>
>>
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>>
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RDXogc066800 for <[e-mail]>; Wed, 27 Aug 2003 06:33:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RDXoBh066799 for ietf-pkix-bks; Wed, 27 Aug 2003 06:33:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RDXhgc066791 for <[e-mail]>; Wed, 27 Aug 2003 06:33:46 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA30058; Wed, 27 Aug 2003 15:38:58 +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 PAA09371; Wed, 27 Aug 2003 15:34:28 +0200
Message-ID: <[e-mail]>
Date: Wed, 27 Aug 2003 15:33:35 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Matt Cooper <[e-mail]>
CC: "'PKIX List'" <[e-mail]>
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
References: <005401c3629a$d4ff1b80$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Matt,

> Hi Denis,

> First, apologies for taking so long to get you a reply.
> 
> You're right, the topic of retrieval (where to find certificates,
> discussions of various sources, how to obtain revocation information, and
> what CAs should put in certs to facilitate all of this) is a very important
> topic that is intimately related to path building. However, I think that
> they are separable topics. 

I do not think so.

The story starts with a target certificate and a candidate trust point.
The question is then using information that may be found both in the 
certificate and in the trust point, how can we find CA certificates and 
certificate revocation information related to a candidate path bewteen the 
target certificate and the candidate trust point.

The "navigation" is subject to which CA certificates can be obtained.

 > Our document shies away from retrieval topics and
> focuses on ideas for how to go about navigating the decision tree once you
> have the certificates. (Perhaps we have put the cart before horse!?) 

Yes, indeed. :-)

 > On the
> other hand, we didn't feel that we could address the topic of building
> without some limited discussion on retrieval. (Hence the rather short
> sections you referred to.)

> I agree with you 110% that additional guidance for both PKI consumers and
> CAs in this area would be very helpful. BUT, in the interest of keeping the
> document from growing out of control, I submit that retrieval would be an
> ideal topic for a new document. 

Certificate retrieval cannot be fully separated from path construction.

 > (In fact, this idea was brought up at the
> meeting in Vienna.) Items A-C in your message would be ideal content for
> such a document. What do you (and others) think of this idea?

I could suggest deletions in your document, but it appears that you think 
that nothing should be suppressed. :-)

In fact, a restructuring of the document would be necessary to mix for each 
step the story of path building and of CA certificate fetching.

Denis

>>From: Denis Pinkas
>>1. The difference between a CA-certificate and a cross-certificate is 
>>still very hazy since what means a "realm" is either left undefined or 
>>is said to be "dependant upon local policy". It is thus impossible to 
>>have standard rules with such an approach.
> 
> 
> I assume you referring to the sorting method that suggests you traverse
> certs from cACertificate prior to crossCertificatePair? This is based solely
> on what we've seen in the field as common practice. So, although realm is a
> fuzzy notion, more often than not (from what I've seen at least) it seems
> that if both cACertificate and crossCertificatePair are populated, that
> cACertificate is the "local realm" and usually confines searches to the
> local network. But, like all the other sorting methods, it won't work all
> the time for every scenario. I personally like this sorting method, but
> there are other dissenters. I certainly wouldn't oppose removal if that
> seems to be the consensus or the group feels it won't contribute to
> optimizing the path building.
> 
> 
>>From: Denis Pinkas
>>Is it really important to make the difference if both:
>>
>>  - the pointers to CA repositories are present, and
>>  - these repositories entries are correctly filled-in ?
> 
> 
> I think so. Retrieving the certs is only half the problem - these pointers
> help you find certs, but they don't necessarily help you decide what to do
> with them once you have them. If we can use some information to guess at
> whether the CA is local to the PKI consumer vs. remote, we can use this to
> try to consume paths from the local (and presumably faster) network first.
> Were you looking for a statement that says use of these sources should
> over-ride other available sources?
> 
> 
>>From: Denis Pinkas
>>Figure 3 does not make sense unless the trust points
>>are indicated.
> 
> 
> Is it necessary for the diagram to indicate which CA (if any of them) is the
> trust point? On the other hand, to make it consistent with the other
> examples, I agree there should be one designated. The other thing I don't
> like about this diagram is that it needs to be 4 or 5 CAs instead of three -
> 3 CAs looks just like a ring topology. I  will change this in the next
> version.
> 
> 
>>From: Denis Pinkas
>>3. The case of validating a certificate in the past after a CA key 
>>rollover (using the new root key) should be addressed.
> 
> 
> Do you mean validating an old certificate at some past T where T precedes
> the notBefore in the cert issued from the new CA key to the old CA key? I
> don't think this should validate. Then on the other side of the notBefore,
> no additional discussion should be necessary, or am I missing what you are
> telling me? I think the current sorting methods will handle key-rollover for
> a T post the notBefore time without a problem.
> 
> 
>>From: Denis Pinkas
>>4. An interesting case to discuss would be the encoding of the issuer 
>>name before and after December 31, 2003 since all certificates issued 
>>after December 31, 2003 MUST use the UTF8String encoding of 
>>DirectoryString (except as noted). The case of "name rollover" 
>>certificates to support an orderly migration to UTF8String encoding 
>>should be explained.
> 
> 
> Excellent idea and thanks for pointing it out. Although, I think we should
> not use  MUST here since this is informational only.
> 
> 
>>From: Denis Pinkas
>>5. The document is far too long.
> 
> 
> Denis, you told me this immediately following a bunch of suggestions on how
> to make it longer! To tell you the truth, I agree, it is rather lengthy. On
> the other hand, I would be reticent to remove any of the sorting discussion.
> And, I think absent a retrieval doc, there needs to be at least some limited
> discussion of retrieval. I'm not certain how to shorten it without removing
> something that others may well find to be of value. Perhaps the sorting
> methods could be moved to an appendix?
> 
> -Matt
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]] 
>>Sent: Tuesday, July 15, 2003 5:23 AM
>>To: Peter Hesse; 'Matt Cooper'; 'Yuriy Dzambasow'; 'Susan 
>>Joseph'; Richard E. Nicholas (Nicholas, Richard)
>>Cc: Steve Hanna; 'PKIX List'
>>Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
>>
>>
>>Comments on certpathbuild-00.txt
>>
>>The title of the document was promising, but the content is 
>>not exactly what 
>>would have been expected.
>>
>>The topic should be how to allow interoperability to find out 
>>the elements 
>>(i.e. both the certificates and the associated revocation status 
>>information) needed for to build a certification path either walking 
>>downwards or upwards the certification tree.
>>
>>The document should explain how inserting some of the 
>>extensions defined in 
>>RFC 3280 will allow to build the certification path, 
>>irrespective of local 
>>conditions (e.g. the user does not have a XX-xxxxxxDirectory where 
>>everything needed is stored. :-)  )
>>
>>Some interesting elements are provided starting page 54, in 
>>sections 6.2 and 
>>6.3. but this is far from sufficient.
>>
>>There are two solutions to this problem, either walking 
>>downwards or upwards 
>>the certification tree.
>>
>>
>>A. Walking downwards the certification tree.
>>
>>Each trust point SHOULD include in the self-signed 
>>certificate the way to 
>>find out where the CA has placed the CA certificates that it 
>>issues. This 
>>SHALL be done using the Subject Information Access extension 
>>defined in 
>>section 4.2.2.2 from RFC 3280.
>>
>>The id-ad-caRepository OID SHALL be used to indicate in which 
>>repository the 
>>CA publishes its certificates and CRLs (if issued).
>>
>>Each CA certificate SHOULD also include the Subject 
>>Information Access 
>>extension defined in section 4.2.2.2. from RFC 3280.
>>
>>This is the preferred method, since anyway trust points MUST be known.
>>
>>
>>B. Walking upwards the certification tree.
>>
>>Each end-entity certificate and each CA certificate SHOULD 
>>include the way 
>>to find out where the CA is placing the other certificates. 
>>This SHALL be 
>>done using the Authority Information Access extension defined 
>>in section 
>>4.2.2.1 from RFC 3280 :
>>
>>The id-ad-caIssuers OID SHALL be used to list where the CA 
>>that has issued 
>>the certificate lists CA certificates issued to the CA.
>>
>>This extension SHOULD be included in end-entity certificates and CA 
>>certificates.
>>
>>This can only be a complement to the previous method, since 
>>anyway trust 
>>points MUST be known. When the downwards approach does not 
>>succeed (explain 
>>in which cases, it may not succeed), then a combination of 
>>both methods may 
>>succeed.
>>
>>Note: The location of CRLs is not specified in this extension. That 
>>information is provided by the cRLDistributionPoints extension.
>>
>>
>>C. Revocation checking
>>
>>For revocation checking each end-entity and CA certificate 
>>SHALL either 
>>include :
>>
>>    a) a cRLDistributionPoints extension, or
>>    b) Subject Information access extension that includes the 
>>id-ad-ocsp OID
>>       to indicate the location of servers using the Online 
>>Certificate
>>       Status Protocol (OCSP) [RFC 2560].
>>
>>
>>Other comments.
>>
>>1. The difference between a CA-certificate and a 
>>cross-certificate is still 
>>very hazy since what means a "realm" is either left undefined 
>>or is said to 
>>be "dependant upon local policy". It is thus impossible to 
>>have standard 
>>rules with such an approach.
>>
>>Introducing naming constraints between subject and issuer 
>>names might be 
>>more appropriate; however, the real question is the following:
>>
>>Is it really important to make the difference if both:
>>
>>  - the pointers to CA repositories are present, and
>>  - these repositories entries are correctly filled-in ?
>>
>>
>>2. There is, as usual, some confusion between cross 
>>certification (which is, 
>>by definition, unilateral) and mutual cross certification 
>>(see section 
>>13.2). Figure 3 does not make sense unless the trust points 
>>are indicated.
>>
>>
>>3. The case of validating a certificate in the past after a 
>>CA key rollover 
>>(using the new root key) should be addressed.
>>
>>
>>4. An interesting case to discuss would be the encoding of 
>>the issuer name 
>>before and after December 31, 2003 since all certificates 
>>issued after 
>>December 31, 2003 MUST use the UTF8String encoding of DirectoryString 
>>(except as noted). The case of "name rollover" certificates 
>>to support an 
>>orderly migration to UTF8String encoding should be explained .
>>
>>
>>5. The document is far too long.
>>
>>
>>Denis
>>
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QMDZgc091154 for <[e-mail]>; Tue, 26 Aug 2003 15:13:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7QMDZo5091153 for ietf-pkix-bks; Tue, 26 Aug 2003 15:13:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from klapautius.it.su.se (as13-3-2.rny.s.bonet.se [217.215.166.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QMDVgc091143 for <[e-mail]>; Tue, 26 Aug 2003 15:13:32 -0700 (PDT) (envelope-from [e-mail])
Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h7QMD4h00360; Wed, 27 Aug 2003 00:13:04 +0200
Message-ID: <[e-mail]>
Date: Wed, 27 Aug 2003 00:13:04 +0200
From: Leif Johansson <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Gietz <[e-mail]>
CC: Stephen Kent <[e-mail]>, todd glassey <[e-mail]>, Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
References: <p05210604bb4eed81d497@[128.89.89.75]> <00f201c357c7$dfc95d10$020aff0a@tsg1> <p05210600bb501fcc5896@[128.89.89.75]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gietz wrote:

>
> I am not really sure on what layer this thread is being discussed, but 
> my feeling is that it is rather on business and political layers than 
> on a technical one.

Probably.

>
> Multi-valued RDNs are not very complicated to support, basically it is 
> one more loop when analysing a DN added to the loop for the single 
> RDN-components of the DN. having found a RDN, you just loop once more 
> to find the single parts of a possibly multi-valued RDN. This can be 
> implemented within one day in any implementation. Most LDAP libraries 
> have a function called explode_RDN or similiar that helps you with 
> this additional loop.

That is not the issue. The issue is that for some reason (conspiracy, 
stupidity, whatever) lots of clients
and applications don't use this feature i.e it is not widely deployed. 
Imo the reason why multivalued
RDNs are seldom seen outside the pki community is that it is just easier 
to add another level to your
DIT. This may not be an option if you are brought up on classical 
structure rules but most LDAP
admins don't know or care about X.500! To them using multivalued RDNs is 
just added complexity
with no extra value.

There are apparently quite a few subscribers to this list who actually 
believe that pki will have any
influence on widely deployed enterprise directories. To me that is quite 
surprising.

>
> There must be other reasons for not wanting to implement that, and I 
> suspect these reasons have more to do with interests in being not 100% 
> compliant to a standard.
>
A big conspiracy eh? ;-) I'd be perfectly happy to have this thread die 
here.

       Cheers Leif



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHHaqt049258 for <[e-mail]>; Fri, 22 Aug 2003 10:17:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MHHaOr049257 for ietf-pkix-bks; Fri, 22 Aug 2003 10:17:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MHHZqt049243 for <[e-mail]>; Fri, 22 Aug 2003 10:17:35 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7MHHV1J025762; Fri, 22 Aug 2003 13:17:31 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210607bb6bff673667@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 22 Aug 2003 13:15:31 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID 	 matching)
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 14:59 +0000 8/22/03, [e-mail] wrote:
>Donning flameproof underpants for this one.
>
>Trust path construction should be done with Distinguished Names
>rather than Key IDs but I feel that, with a bit of work, Key IDs could
>be made into a reliable mechanism and one that would permit
>local trust path construction in the continuing absence of a public global
>directory. It requires that the Key IDs can only be generated at the same
>time as, and by the same device as, the keys themselves. RFC3280 states
>that a Key ID need only be generated if there is not one already present
>and merely copied when present. Employing this method would mask out
>local differences in the interpretations of Key ID algorithms. If the value
>of the keys can be relied on then so can the trust paths that can be built
>using them.
>
>Toast ?
>
>Chris

Chris,

I cannot interpret what you said, relative to what you indicated was 
the goal of this message. Are you saying that with a simple 
convention on how SKIDs are managed in CA certs, that one can use 
AKIDs to locate CA certs? if so, it is not at all clear from your 
message.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFZcqt044403 for <[e-mail]>; Fri, 22 Aug 2003 08:35:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MFZcfB044402 for ietf-pkix-bks; Fri, 22 Aug 2003 08:35:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MFZbqt044397 for <[e-mail]>; Fri, 22 Aug 2003 08:35:37 -0700 (PDT) (envelope-from [e-mail])
Received: from phessel ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id LAA320815; Fri, 22 Aug 2003 11:35:35 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
Date: Fri, 22 Aug 2003 11:35:00 -0400
Organization: Gemini Security Solutions, Inc.
Message-ID: <004a01c368c2$f3467150$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris,

As was already mentioned on the list, there is no requirement that
SKID/AKID match.  While it would be nice if it can be counted on, I
think that it just flat out can't; so you can't create your path
development routine to require this to be in place.

Besides this pertinent fact, there is another I'd like you to consider.
SKID/AKID are only available once the certificate has been downloaded
and parsed.  If you are attempting to build a certification path based
upon a target certificate and a pointer to an LDAP directory, relying on
SKID/AKID only (and not name/public key chaining) could require the
download of many insignificant certificates.  

I suspect chaining of distinguished names will be the most important
part of path building for quite some time.  Once you retrieve
certificates for the appropriate entity, then it makes perfect sense to
check the certificates for which the SKID/AKID match appropriately first
when the path is being built; it is my assertion that you can't just
stop there.

--Peter

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


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, August 22, 2003 10:59 AM
To: [e-mail]
Cc: [e-mail]
Subject: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID
matching)





Donning flameproof underpants for this one.

Trust path construction should be done with Distinguished Names rather
than Key IDs but I feel that, with a bit of work, Key IDs could be made
into a reliable mechanism and one that would permit local trust path
construction in the continuing absence of a public global directory. It
requires that the Key IDs can only be generated at the same time as, and
by the same device as, the keys themselves. RFC3280 states that a Key ID
need only be generated if there is not one already present and merely
copied when present. Employing this method would mask out local
differences in the interpretations of Key ID algorithms. If the value of
the keys can be relied on then so can the trust paths that can be built
using them.

Toast ?

Chris



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDxjqt035367 for <[e-mail]>; Fri, 22 Aug 2003 06:59:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MDxjxB035366 for ietf-pkix-bks; Fri, 22 Aug 2003 06:59:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MDxiqt035361 for <[e-mail]>; Fri, 22 Aug 2003 06:59:44 -0700 (PDT) (envelope-from [e-mail])
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 937FC1226DE for <[e-mail]>; Fri, 22 Aug 2003 14:59:44 +0100 (BST)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256D8A.005264CD ; Fri, 22 Aug 2003 14:59:57 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 22 Aug 2003 14:59:08 +0000
Subject: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Donning flameproof underpants for this one.

Trust path construction should be done with Distinguished Names
rather than Key IDs but I feel that, with a bit of work, Key IDs could
be made into a reliable mechanism and one that would permit
local trust path construction in the continuing absence of a public global
directory. It requires that the Key IDs can only be generated at the same
time as, and by the same device as, the keys themselves. RFC3280 states
that a Key ID need only be generated if there is not one already present
and merely copied when present. Employing this method would mask out
local differences in the interpretations of Key ID algorithms. If the value
of the keys can be relied on then so can the trust paths that can be built
using them.

Toast ?

Chris




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MD8Lqt032246 for <[e-mail]>; Fri, 22 Aug 2003 06:08:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MD8LZK032242 for ietf-pkix-bks; Fri, 22 Aug 2003 06:08:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MD8Jqt032232 for <[e-mail]>; Fri, 22 Aug 2003 06:08:19 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V7MD04NH24977 for <[e-mail]>; Fri, 22 Aug 2003 09:04:23 -0400
Received: (qmail 20073 invoked by uid 64014); 22 Aug 2003 13:00:32 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.314184 secs); 22 Aug 2003 13:00:32 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by 10.4.61.249 with SMTP; 22 Aug 2003 13:00:31 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <RFJRNJWS>; Fri, 22 Aug 2003 09:08:13 -0400
Message-ID: <[e-mail]>
From: Tim Moses <[e-mail]>
To: "'L Williams'" <[e-mail]>, "'Steve Hanna'" <[e-mail]>
Cc: [e-mail]
Subject: RE: 3280 Question WRT SKID/AKID matching
Date: Fri, 22 Aug 2003 09:08:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Laudon - I think a little bit more care is required, since, unless the CA is
in a hierarchy, it may have more than one "inbound" certificate.  If their
SKIs are to populate the AKI of its "outbound" certificates, then they had
better all be the same.  This can happen if there is a single standard way
of calculating a SKI or the subject chooses it him/herself.

No matter, chaining SKI/AKI provides no additional benefit over chaining
public-key/signature and Subject/Issuer values.

All the best.  Tim.

-----Original Message-----
From: L Williams [mailto:[e-mail]]
Sent: Thursday, August 21, 2003 3:59 PM
To: 'Steve Hanna'
Cc: [e-mail]
Subject: RE: 3280 Question WRT SKID/AKID matching





I'll mention in passing why such a requirement would
be a bad idea. If you're a CA, you may not be able to
control the SKIDs that other CAs put in their cross
certificates for you. They may not use the same method
for calculating key identifiers that you use for your
AKID (since RFC 3280 allows several different methods).

[LW] In practicality, I'm not so sure this *is* a problem, since most CAs
generate the cross-certificates based on the CA's existing certificate.
Doing a binary copy of the existing certificate's SKI into the
cross-certificate's SKI is trivial.

-Laudon


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9tBqt017107 for <[e-mail]>; Fri, 22 Aug 2003 02:55:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M9tBUI017106 for ietf-pkix-bks; Fri, 22 Aug 2003 02:55:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.27]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M9t9qt017074 for <[e-mail]>; Fri, 22 Aug 2003 02:55:09 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft3.fr.colt.net with ESMTP id h7M9t2W05808 for <[e-mail]>; Fri, 22 Aug 2003 11:55:02 +0200
Message-ID: <[e-mail]>
Date: Fri, 22 Aug 2003 11:55:16 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030811
X-Accept-Language: en, fr, en-us, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: 3280 Question WRT SKID/AKID matching
References: <005301c3684e$076ba9e0$1b0aa8c0@odin>
In-Reply-To: <005301c3684e$076ba9e0$1b0aa8c0@odin>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Hesse wrote:
> It may be trivial, but I have seen in practice that many commerical CA
> products develop their own SKI when issuing a cross-certificate.
> Usually it depends on how the software accepts the request for
> cross-certification.  (It's easier to provide the SKI in a self-signed
> certificate than say in a PKCS#10 request.)

I think it's a *very* bad idea to do such a thing and I'd personnally be 
in favor of adding some text to explicitly exclude that in son-of-rfc3280.

I'd change :

To facilitate certification path construction, this extension MUST 
appear in all conforming CA certificates, that is, all certificates 
including the basic constraints extension (section 4.2.1.10) where the 
value of cA is TRUE.  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.

to :

To facilitate certification path construction, this extension MUST 
appear in all conforming CA certificates, that is, all certificates 
including the basic constraints extension (section 4.2.1.10) where the 
value of cA is TRUE.  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. When creating a cross-certificate for an 
external CA, the value of the subject key identifier included inside the 
cross-certificate MUST be the copy of the value of the subject key 
identifier of the original certificate of this CA.

But to answer the original question, in my opinion, they are two 
separate steps :
- creating a certificate :
 From the above quoted text, RFC3280 requires AKI and SKI to match when 
creating a certificate

- validating a certificate :
The validation algorythm in 6 doesn't explicitly require to reject 
certificates where the AKI and SKI do not match.
It's not explicit that "processing" the AKI extension means you must 
reject a certificate if the AKI does not match the SKI of it's potential 
emitter. If that's intended, a more explicit text would be useful.

In the present situation, I'd consider such a certificate can be 
validated, just like a rfc2459 certificate that would not respect some 
more stringent rules of rfc3280 could be used for path validation, as 
long as it does not break an explicit rule of path validation in rfc3280.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M1c7qt070858 for <[e-mail]>; Thu, 21 Aug 2003 18:38:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M1c7Av070857 for ietf-pkix-bks; Thu, 21 Aug 2003 18:38:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lakemtao03.cox.net (lakemtao03.cox.net [68.1.17.242]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M1c5qt070850 for <[e-mail]>; Thu, 21 Aug 2003 18:38:06 -0700 (PDT) (envelope-from [e-mail])
Received: from odin ([68.100.62.56]) by lakemtao03.cox.net (InterMail vM.5.01.06.04 201-253-122-130-104-20030726) with ESMTP id <20030822013802.FXWW10977.lakemtao03.cox.net@odin>; Thu, 21 Aug 2003 21:38:02 -0400
From: "Peter Hesse" <[e-mail]>
To: "'L Williams'" <[e-mail]>, "'Steve Hanna'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: 3280 Question WRT SKID/AKID matching
Date: Thu, 21 Aug 2003 21:38:03 -0400
Message-ID: <005301c3684e$076ba9e0$1b0aa8c0@odin>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <000801c3681e$bb8c2f60$6401a8c0@gnosis>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It may be trivial, but I have seen in practice that many commerical CA
products develop their own SKI when issuing a cross-certificate.
Usually it depends on how the software accepts the request for
cross-certification.  (It's easier to provide the SKI in a self-signed
certificate than say in a PKCS#10 request.)  I won't name names, but I
will say that it was a definite problem in the first few demonstrations
involving Bridge Certification Authorities.

Caveat creator!  (Loosely: let the implementer beware!)

--Peter

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of L Williams
Sent: Thursday, August 21, 2003 3:59 PM
To: 'Steve Hanna'
Cc: [e-mail]
Subject: RE: 3280 Question WRT SKID/AKID matching





I'll mention in passing why such a requirement would
be a bad idea. If you're a CA, you may not be able to
control the SKIDs that other CAs put in their cross certificates for
you. They may not use the same method for calculating key identifiers
that you use for your AKID (since RFC 3280 allows several different
methods).

[LW] In practicality, I'm not so sure this *is* a problem, since most
CAs generate the cross-certificates based on the CA's existing
certificate. Doing a binary copy of the existing certificate's SKI into
the cross-certificate's SKI is trivial.

-Laudon



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LLbnqt058939 for <[e-mail]>; Thu, 21 Aug 2003 14:37:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LLbn7X058938 for ietf-pkix-bks; Thu, 21 Aug 2003 14:37:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LLblqt058933 for <[e-mail]>; Thu, 21 Aug 2003 14:37:47 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7LLbi1J003912; Thu, 21 Aug 2003 17:37:44 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210613bb6ae7eb0ae0@[128.89.88.34]>
In-Reply-To:  <[e-mail].a u>
References:  <[e-mail].a u>
Date: Thu, 21 Aug 2003 17:34:19 -0400
To: "Manger, James H" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: IP addr: 01: WG last call
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:13 +1000 8/21/03, Manger, James H wrote:
>1.
>Instead of a BOOLEAN type for which TRUE is required and FALSE is 
>forbidden, simply use a NULL type.
>
>Change the type of the inherit fields in IPAddressChoice (2.2.3) and 
>ASIdentifierChoice (3.2.3) to the following:
>
>    IPAddressChoice     ::= CHOICE {
>       inherit              NULL, -- Inherit from Issuer
>       addressesOrRanges    SEQUENCE OF IPAddressOrRange }
>
>    ASIdentifierChoice ::= CHOICE {
>       inherit             NULL, -- Inherit from Issuer
>       asIdsOrRanges       SEQUENCE OF ASIdOrRange }
>
>The associated text describing the inherit fields (2.2.3.5 & 
>3.2.3.3) can be simplified as follows:
>
>"2.2.3.5.  Element inherit
>
>    If the IPAddressChoice choice contains the inherit element, then 
>the set of authorized IP addresses for the specified AFI and 
>optional SAFI is taken from the Issuer's certificate, or the 
>Issuer's Issuer's certificate, recursively, until a certificate 
>containing an IPAddressChoice containing an addressesOrRanges 
>element is located.  If no authorization is being granted for a 
>particular AFI and optional SAFI, then there SHOULD NOT be an 
>IPAddressFamily member for that AFI/SAFI in the IPAddrBlocks 
>sequence."

This does appear to be a reasonable simplification of the ASN.1.  I 
checked with Charlie and he has no objection to making this change.


>2. [previously answered]
>
>
>3.
>Why does everything have to be sorted?  Does it really make it 
>easier or faster for CAs and relying parties, or just harder to 
>implement & more fragile to interoperate?

Sorting of the addresses or As numbers makes it easier for an RP to 
do the path processing, since the sorting allows for easy, one-pass 
subset comparison.  It does impose a requirement on CAs to sort the 
values when a cert is created.  Since a CA need do this only when it 
issues a cert, but an RP gets to take advantage of the sorting very 
time a verification is performed, it seems like a good design 
tradeoff.

>4.
>Section 2.3 says delegations in a certificate must be a subset of 
>the delegations in its issuer's certificate.  What does this mean 
>for certificate path processing inputs and self-signed trust anchor 
>certificates?  If a trust anchor is provided in the form of a 
>self-signed certificate must it contain the delegation extension for 
>the path to be valid?  Is some sort of "initial-delegation-set" 
>required as a path processing input (or, perhaps, a boolean flag 
>indicating if each sort of delegation is allowed or disallowed)?
>

Good question. A trust anchor always requires some special handling 
in path processing, as a close reading of 3280 shows. In this case 
the intent is to treat a TA as trivially satisfying the subset 
requirement, i.e., whatever values the extensions contain are OK as a 
starting point, to initialize the path processing checks on the 
subset requirement. after all a set is a subset of itself :-)

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LJxTqt052512 for <[e-mail]>; Thu, 21 Aug 2003 12:59:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LJxTRn052511 for ietf-pkix-bks; Thu, 21 Aug 2003 12:59:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from orb.pobox.com (orb.pobox.com [216.65.124.72]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LJxSqt052504 for <[e-mail]>; Thu, 21 Aug 2003 12:59:28 -0700 (PDT) (envelope-from [e-mail])
Received: from texas.pobox.com (texas.pobox.com[64.49.223.111]) by orb.pobox.com (Postfix) with ESMTP id CCD2B1561B8; Thu, 21 Aug 2003 15:59:30 -0400 (EDT)
Received: from gnosis (12-230-199-189.client.attbi.com [12.230.199.189]) by texas.pobox.com (Postfix) with ESMTP id 0B21B453EE; Thu, 21 Aug 2003 15:59:30 -0400 (EDT)
From: "L Williams" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: 3280 Question WRT SKID/AKID matching
Date: Thu, 21 Aug 2003 12:59:29 -0700
Message-ID: <000801c3681e$bb8c2f60$6401a8c0@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
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'll mention in passing why such a requirement would
be a bad idea. If you're a CA, you may not be able to
control the SKIDs that other CAs put in their cross
certificates for you. They may not use the same method
for calculating key identifiers that you use for your
AKID (since RFC 3280 allows several different methods).

[LW] In practicality, I'm not so sure this *is* a problem, since most CAs
generate the cross-certificates based on the CA's existing certificate.
Doing a binary copy of the existing certificate's SKI into the
cross-certificate's SKI is trivial.

-Laudon



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LEaIqt033767 for <[e-mail]>; Thu, 21 Aug 2003 07:36:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LEaIcZ033766 for ietf-pkix-bks; Thu, 21 Aug 2003 07:36:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LEaHqt033748 for <[e-mail]>; Thu, 21 Aug 2003 07:36:17 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7LEaC5q018420; Thu, 21 Aug 2003 07:36:12 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h7LEaBs11257; Thu, 21 Aug 2003 10:36:11 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 21 Aug 2003 10:32:31 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matt Cooper <[e-mail]>
CC: [e-mail]
Subject: Re: 3280 Question WRT SKID/AKID matching
References: <002001c36736$c77f00b0$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6A4FDACAA5F48CEEF681EBC9"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Matt,

I'm surprised nobody has answered your question yet.
I guess everybody's on vacation!

RFC 3280 does NOT require subject and authority key
identifiers to match. I don't believe there's an
explicit statement to that effect, but section 6.1
(which describes the validation algorithm) doesn't
refer to key identifiers at all. And sections 4.2.1.1
and 4.2.1.2 (which describe the AKID and SKID extensions)
say nothing about requiring them to match for validation.
They say instead that these extensions are used to
"facilitate certification path construction".

Apparently, this is a common misconception. I suggest
that the successor to RFC 3280 explain clearly that
there's no requirement that AKID and SKID match for
a path to be valid.

I'll mention in passing why such a requirement would
be a bad idea. If you're a CA, you may not be able to
control the SKIDs that other CAs put in their cross
certificates for you. They may not use the same method
for calculating key identifiers that you use for your
AKID (since RFC 3280 allows several different methods).

Thanks for asking. It's always good to clarify any
ambiguities. And if anyone else has a good argument
that my interpretation of RFC 3280 wrong, please
speak up.

Take care,

Steve Hanna

Matt Cooper wrote:
> 
> As many of you are aware, the problem of mismatched SKIDs and AKIDs have
> caused many interoperability problems between vendors in the past when it
> comes to cross certification. This can happen for a variety of reasons, but
> is usually to do with how the KeyID is calculated. X.509 indicates that
> SKID/AKID match provides path building guidance; matching is not required in
> order to have a valid path.
> 
> There was mention at the IETF conference that 3280 required subject and
> authority key ID's to match; with the inference being that the path would be
> invalid if they did not. However, I've looked again and I'm not necessarily
> reading that into what is in the text; though I see how it could be read
> that way.
> 
> Clearly stated is what a CA must put into the certificate with regard to
> AKID and SKID, but it is not stated that a path that did not adhere to this
> should be considered invalid. I definitely lean toward not requiring a match
> for validation, but would be interested to hear other's (especially the 3280
> author's) thoughts.
> 
> From authorityKeyID:
> =======================================
> The keyIdentifier field of the authorityKeyIdentifier extension MUST be
> included in all certificates generated by conforming CAs to facilitate
> certification path construction.
> 
> From subjectKeyID:
> =======================================
> To facilitate certification path construction, this extension MUST appear in
> all conforming CA certificates, that is, all certificates including the
> basic constraints extension (section 4.2.1.10) where the value of cA is
> TRUE.  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.
> 
> Matt Cooper
> Orion Security Solutions
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> (Mob) 703.981.2269
> (Off) 703.917.0060
> (Fax) 703.917.0260
> Visit our website!
> http://www.orionsec.com
--------------ms6A4FDACAA5F48CEEF681EBC9
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
CQUxDxcNMDMwODIxMTQzMjMyWjAjBgkqhkiG9w0BCQQxFgQU9DPB5XDA9/0jwd0LNcLiPlrq
jNkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAUDWEc
2Q1jqBiiMmoKgovvO13/Beq6iGXihptDxEQXUmGRqdS8c7JNG0u8AlaGHcLHr/Ef6Rk/SMZQ
pRIHz2NeS5xTzYeLfO3+fQMyL6vVa1r7hqdr5s12IAfzs1itjxo8an8BfAShq/0UpAcCSkpC
XNHLYB+QisQQ1MJ7hrZk+A==
--------------ms6A4FDACAA5F48CEEF681EBC9--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L0Rlqt065645 for <[e-mail]>; Wed, 20 Aug 2003 17:27:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7L0Rlou065643 for ietf-pkix-bks; Wed, 20 Aug 2003 17:27:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.ntcif.telstra.com.au ([202.12.233.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7L0Riqt065638 for <[e-mail]>; Wed, 20 Aug 2003 17:27:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from uucp@localhost) by mailbo.ntcif.telstra.com.au (8.8.2/8.6.9) id KAA24520 for <[e-mail]>; Thu, 21 Aug 2003 10:27:35 +1000 (EST)
Received: from mailbi.ntcif.telstra.com.au(202.12.162.19) via SMTP by mailbo.ntcif.telstra.com.au, id smtpdklaaWT; Thu Aug 21 10:26:22 2003
Received: (from uucp@localhost) by mailbi.ntcif.telstra.com.au (8.8.2/8.6.9) id KAA10738 for <[e-mail]>; Thu, 21 Aug 2003 10:26:20 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdbSaa9r; Thu Aug 21 10:24:46 2003
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA01088 for <[e-mail]>; Thu, 21 Aug 2003 10:24:46 +1000 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: IP addr: 01: WG last call
Date: Thu, 21 Aug 2003 10:13:54 +1000
Message-ID: <[e-mail]>
Thread-Topic: WG last call
Thread-Index: AcNm1qUYnho9FOpOTSKRH8JT9h3K4wAofiJw
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7L0Rkqt065639
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1.
Instead of a BOOLEAN type for which TRUE is required and FALSE is forbidden, simply use a NULL type.

Change the type of the inherit fields in IPAddressChoice (2.2.3) and ASIdentifierChoice (3.2.3) to the following:

   IPAddressChoice     ::= CHOICE {
      inherit              NULL, -- Inherit from Issuer
      addressesOrRanges    SEQUENCE OF IPAddressOrRange }

   ASIdentifierChoice ::= CHOICE {
      inherit             NULL, -- Inherit from Issuer
      asIdsOrRanges       SEQUENCE OF ASIdOrRange }

The associated text describing the inherit fields (2.2.3.5 & 3.2.3.3) can be simplified as follows:

"2.2.3.5.  Element inherit

   If the IPAddressChoice choice contains the inherit element, then the set of authorized IP addresses for the specified AFI and optional SAFI is taken from the Issuer's certificate, or the Issuer's Issuer's certificate, recursively, until a certificate containing an IPAddressChoice containing an addressesOrRanges element is located.  If no authorization is being granted for a particular AFI and optional SAFI, then there SHOULD NOT be an IPAddressFamily member for that AFI/SAFI in the IPAddrBlocks sequence."


2. [previously answered]


3.
Why does everything have to be sorted?  Does it really make it easier or faster for CAs and relying parties, or just harder to implement & more fragile to interoperate?


4.
Section 2.3 says delegations in a certificate must be a subset of the delegations in its issuer's certificate.  What does this mean for certificate path processing inputs and self-signed trust anchor certificates?  If a trust anchor is provided in the form of a self-signed certificate must it contain the delegation extension for the path to be valid?  Is some sort of "initial-delegation-set" required as a path processing input (or, perhaps, a boolean flag indicating if each sort of delegation is allowed or disallowed)?


	----------
	From: 	Stephen Kent [mailto:[e-mail]] 
	Sent:	Thursday, 17 July 2003 4:57 PM

	..The model envisioned here requires that all CA certs on the path contain the extension, terminating in an EE cert containing the extension. We couild clarify this in a revision of the doc.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGNbqt024519 for <[e-mail]>; Wed, 20 Aug 2003 09:23:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGNbXY024518 for ietf-pkix-bks; Wed, 20 Aug 2003 09:23:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGNZqt024511 for <[e-mail]>; Wed, 20 Aug 2003 09:23:36 -0700 (PDT) (envelope-from [e-mail])
Received: from wmcooper (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h7KGJ6kU024976; Wed, 20 Aug 2003 12:19:06 -0400
From: "Matt Cooper" <[e-mail]>
To: <[e-mail]>
Subject: 3280 Question WRT SKID/AKID matching
Date: Wed, 20 Aug 2003 12:18:56 -0400
Message-ID: <002001c36736$c77f00b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7KGNaqt024512
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As many of you are aware, the problem of mismatched SKIDs and AKIDs have
caused many interoperability problems between vendors in the past when it
comes to cross certification. This can happen for a variety of reasons, but
is usually to do with how the KeyID is calculated. X.509 indicates that
SKID/AKID match provides path building guidance; matching is not required in
order to have a valid path.

There was mention at the IETF conference that 3280 required subject and
authority key ID's to match; with the inference being that the path would be
invalid if they did not. However, I've looked again and I'm not necessarily
reading that into what is in the text; though I see how it could be read
that way. 

Clearly stated is what a CA must put into the certificate with regard to
AKID and SKID, but it is not stated that a path that did not adhere to this
should be considered invalid. I definitely lean toward not requiring a match
for validation, but would be interested to hear other's (especially the 3280
author's) thoughts.


>From authorityKeyID:
=======================================
The keyIdentifier field of the authorityKeyIdentifier extension MUST be
included in all certificates generated by conforming CAs to facilitate
certification path construction.

>From subjectKeyID:
=======================================
To facilitate certification path construction, this extension MUST appear in
all conforming CA certificates, that is, all certificates including the
basic constraints extension (section 4.2.1.10) where the value of cA is
TRUE.  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.


Matt Cooper
Orion Security Solutions
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101
(Mob) 703.981.2269
(Off) 703.917.0060
(Fax) 703.917.0260
Visit our website!
http://www.orionsec.com




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K225qt048573 for <[e-mail]>; Tue, 19 Aug 2003 19:02:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7K225Va048572 for ietf-pkix-bks; Tue, 19 Aug 2003 19:02:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7K224qt048564 for <[e-mail]>; Tue, 19 Aug 2003 19:02:04 -0700 (PDT) (envelope-from [e-mail])
Received: from [12.159.173.175] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7K21v1J002927 for <[e-mail]>; Tue, 19 Aug 2003 22:01:59 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210603bb6883b3023b@[12.159.173.175]>
Date: Tue, 19 Aug 2003 22:02:06 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WG last call
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

We have a relatively old ID that was reposted in June, after minor 
changes in response to some previous comments. The document defines 
two proposed extensions, one to carry IP address prefix data and one 
to carry Autonomous System Identifier info, in PK certs. The 
extension was developed to enable creation of a PKI that reflects the 
assignment of IP addresses and AS numbers, which happens to be done 
in a top down, singly rooted tree fashion, starting with IANA. The 
document is draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.

I would like to initiate a 2-week WG last call on this ID. There are 
now a couple of protocols that could make use of this extension in 
different contexts and so it would be good to have it as another, 
completed PKIX item.

Since I am a co-author of the document, I will recuse myself from the 
process of determining WG consensus in this case, and rely on Tim to 
deal with any issues that may arise.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IH5gqt017882 for <[e-mail]>; Mon, 18 Aug 2003 10:05:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IH5g22017881 for ietf-pkix-bks; Mon, 18 Aug 2003 10:05:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IH5fqt017876 for <[e-mail]>; Mon, 18 Aug 2003 10:05:41 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h7IH5cUh012560; Mon, 18 Aug 2003 10:05:38 -0700 (PDT)
Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <Q0M3F4ZA>; Mon, 18 Aug 2003 10:05:38 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, Rich Salz <[e-mail]>, "Deacon, Alex" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
Date: Mon, 18 Aug 2003 10:05:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C365AA.F1C12AC0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C365AA.F1C12AC0
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks all for the input.  Perhaps my WSDL suggestion was a little
"academic", and I agree in practice its a little heavyweight.  
 
So, I will update the draft as follows:
 
Specify XKMS over SOAP.
 
Clarify and rename the OID to specify XKMS-Validate only.
 
Make support for X509Certificate a MUST.  As an alternative I also like
X509IssuerSerial as a MUST as it makes requests smaller which is nice in
some mobile environments.  As for X509Data, I suppose supporting this makes
sense if we want to allow a single request to contain more then 1 cert.
(I.e. please validate these 12 certs).  My inclination is to keep things
simple and not allow this in this profile, especially since XKMS validates
the whole chain, not just a single cert.  But to be honest I don't have a
strong opinion so let me know what you think.
 
Borrow the OCSP trust model where responses can be CA signed, CA delegated
or trusted via some out of band mechanism (other).
 
Regards,
Alex
 
 
 

-----Original Message-----
From: Ryan M. Hurst [mailto:[e-mail]]
Sent: Monday, August 18, 2003 8:07 AM
To: Rich Salz; Deacon, Alex
Cc: [e-mail]; [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt


Rich - in-line

  _____  

From: Rich Salz
Sent: Fri 8/15/2003 6:12 PM
To: Deacon, Alex
Cc: Ryan M. Hurst; [e-mail]; [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt



> So the XKMS AIA would simply point to a WSDL file that defines where the 
> XKMS service lives, what transport should be used, is a SOAP envelope 
> required, what services are provided and even perhaps even details as to 
> what key identification forms can be sent and what the trust model is. 

Uhm, yuck. :) 

Are you really expecting every XKMS request to start out with a 
GET If-modified-since request?  And then have to parse WSDL to understand 
what do do?  Again, every single XKMS request and every single XKMS client? 

If you don't expect XKMS applications to do the conditional GET, then it's 
not a URL, but is instead a URI.  At that point, it becomes an identifier 
for *a particular instance* of a WSDL file defining the service.  At that 
point, you might as following standard AIA practice, and let the OID 
define the service and transport, and the value define how to find it. 

The only profile worth defining is XKMS over SOAP 1.1 and SOAP 1.2, 
and the value of the OID is a URL of the service that can tell you 
how to Validate the certificate.  Mandate "ds:X509Data/ds:X509Certificate" 
MUST be supported, and that other forms MAY be supported.  Leave it 
up to WS-I (when they get to us) to profile what MAYs should become 
MUSTs. 

[rmh] I agree, however in the case of a certifcate validation engine I can't
imagine a case when anything other that a X509Certificate would be used for
key evaluation, but with that being said as long as there is the MUST for
support of x509 based identification thats workable.

I think it makes little sense, for example, for a cert to 
say "here's the Register service if you want to make more like me." :) 

[rmh] I agree,  my point is that we should be explicit in the draft.

 

I think Ryan's questions are slightly interesting, but only if you 
think a certificate is going to contain multiple AIA's.  I don't. 
In general, his questions are leading us to the morass of "PKI-ness" 
that has, so far, managed to throttle PKI in its crib. 

[rmh] I think support for multiple AIAs is important, also these concepts
must be explicit in a PKIX draft like this otherwise existing certificate
validation engines would make a different set of assumtions resulting in
non-interoperable deployments.


        /r$ 
-- 
Rich Salz                  Chief Security Architect 
DataPower Technology       http://www.datapower.com/
<http://www.datapower.com/>  
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
<http://www.datapower.com/products/xs40.html>  
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html
<http://www.datapower.com/xmldev/xmlsecurity.html>  


------_=_NextPart_001_01C365AA.F1C12AC0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: I-D ACTION:draft-deacon-xkms-aia-00.txt</TITLE>

<META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" size=2>Thanks all 
for the input.&nbsp; Perhaps my WSDL suggestion was a little "academic", and I 
agree in practice its a little heavyweight.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" size=2>So, I will 
update the draft as follows:</FONT></SPAN></DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" size=2>Specify XKMS 
over SOAP.</FONT></SPAN></DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2></FONT></SPAN><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" size=2>Clarify and 
rename&nbsp;the OID to specify XKMS-Validate only.</FONT></SPAN></DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" size=2>Make support 
for X509Certificate a MUST.&nbsp; As an alternative I also like X509IssuerSerial 
as a MUST as it makes requests smaller which is nice in some mobile 
environments.&nbsp; As for X509Data, I suppose supporting this makes sense if we 
want to allow a single request to contain more then 1 cert.&nbsp; (I.e. please 
validate these 12 certs).&nbsp; My inclination is to keep things simple and not 
allow this in this profile, especially since XKMS validates the whole chain, not 
just a single cert.&nbsp; But to be honest I don't have a strong opinion so let 
me know what you think.</FONT></SPAN></DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" size=2>Borrow the 
OCSP trust model where responses can be CA signed, CA delegated or trusted via 
some out of band mechanism (other).</FONT></SPAN></DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2>Alex</FONT></SPAN></DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=649012916-18082003>&nbsp;</SPAN></DIV>
<DIV><SPAN class=649012916-18082003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Ryan M. Hurst 
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, August 18, 2003 
  8:07 AM<BR><B>To:</B> Rich Salz; Deacon, Alex<BR><B>Cc:</B> [e-mail]; 
  [e-mail]<BR><B>Subject:</B> RE: I-D 
  ACTION:draft-deacon-xkms-aia-00.txt<BR><BR></FONT></DIV>
  <DIV id=idOWAReplyText71735 dir=ltr>
  <DIV dir=ltr><FONT face=Arial size=2>Rich - in-line</FONT></DIV></DIV>
  <DIV dir=ltr><BR>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> Rich Salz<BR><B>Sent:</B> Fri 8/15/2003 
  6:12 PM<BR><B>To:</B> Deacon, Alex<BR><B>Cc:</B> Ryan M. Hurst; 
  [e-mail]; [e-mail]<BR><B>Subject:</B> RE: I-D 
  ACTION:draft-deacon-xkms-aia-00.txt<BR></FONT><BR></DIV>
  <DIV>
  <P><FONT size=2>&gt; So the XKMS AIA would simply point to a WSDL file that 
  defines where the</FONT> <BR><FONT size=2>&gt; XKMS service lives, what 
  transport should be used, is a SOAP envelope</FONT> <BR><FONT size=2>&gt; 
  required, what services are provided and even perhaps even details as 
  to</FONT> <BR><FONT size=2>&gt; what key identification forms can be sent and 
  what the trust model is.</FONT> </P>
  <P><FONT size=2>Uhm, yuck. :)</FONT> </P>
  <P><FONT size=2>Are you really expecting every XKMS request to start out with 
  a</FONT> <BR><FONT size=2>GET If-modified-since request?&nbsp; And then have 
  to parse WSDL to understand</FONT> <BR><FONT size=2>what do do?&nbsp; Again, 
  every single XKMS request and every single XKMS client?</FONT> </P>
  <P><FONT size=2>If you don't expect XKMS applications to do the conditional 
  GET, then it's</FONT> <BR><FONT size=2>not a URL, but is instead a URI.&nbsp; 
  At that point, it becomes an identifier</FONT> <BR><FONT size=2>for *a 
  particular instance* of a WSDL file defining the service.&nbsp; At that</FONT> 
  <BR><FONT size=2>point, you might as following standard AIA practice, and let 
  the OID</FONT> <BR><FONT size=2>define the service and transport, and the 
  value define how to find it.</FONT> </P>
  <P><FONT size=2>The only profile worth defining is XKMS over SOAP 1.1 and SOAP 
  1.2,</FONT> <BR><FONT size=2>and the value of the OID is a URL of the service 
  that can tell you</FONT> <BR><FONT size=2>how to Validate the 
  certificate.&nbsp; Mandate "ds:X509Data/ds:X509Certificate"</FONT> <BR><FONT 
  size=2>MUST be supported, and that other forms MAY be supported.&nbsp; Leave 
  it</FONT> <BR><FONT size=2>up to WS-I (when they get to us) to profile what 
  MAYs should become</FONT> <BR><FONT size=2>MUSTs.</FONT> </P>
  <P>[rmh] I agree, however in the case of a certifcate validation engine I 
  can't imagine a case when anything other that a X509Certificate would be used 
  for key evaluation, but with that being said as long as there is the MUST for 
  support of x509 based identification thats workable.</P>
  <P><FONT size=2>I think it makes little sense, for example, for a cert 
  to</FONT> <BR><FONT size=2>say "here's the Register service if you want to 
  make more like me." :)</FONT> </P>
  <P>[rmh] I agree,&nbsp; my point is that we should be explicit in the 
  draft.</P>
  <P>&nbsp;</P>
  <P><FONT size=2>I think Ryan's questions are slightly interesting, but only if 
  you</FONT> <BR><FONT size=2>think a certificate is going to contain multiple 
  AIA's.&nbsp; I don't.</FONT> <BR><FONT size=2>In general, his questions are 
  leading us to the morass of "PKI-ness"</FONT> <BR><FONT size=2>that has, so 
  far, managed to throttle PKI in its crib.</FONT> </P>
  <P>[rmh] I think support for multiple AIAs&nbsp;is important, also these 
  concepts must be explicit in a PKIX draft like this otherwise 
  existing&nbsp;certificate validation engines would make a different 
  set&nbsp;of assumtions resulting in non-interoperable deployments.</P>
  <P><BR><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /r$</FONT> 
  <BR><FONT size=2>--</FONT> <BR><FONT size=2>Rich 
  Salz&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Chief Security Architect</FONT> <BR><FONT size=2>DataPower 
  Technology&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A 
  href="http://www.datapower.com/" 
  target=_blank>http://www.datapower.com/</A></FONT> <BR><FONT size=2>XS40 XML 
  Security Gateway&nbsp; <A href="http://www.datapower.com/products/xs40.html" 
  target=_blank>http://www.datapower.com/products/xs40.html</A></FONT> <BR><FONT 
  size=2>XML Security Overview&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A 
  href="http://www.datapower.com/xmldev/xmlsecurity.html" 
  target=_blank>http://www.datapower.com/xmldev/xmlsecurity.html</A></FONT> 
  </P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C365AA.F1C12AC0--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IF8Lqt013795 for <[e-mail]>; Mon, 18 Aug 2003 08:08:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IF8LMP013794 for ietf-pkix-bks; Mon, 18 Aug 2003 08:08:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IF8Jqt013786 for <[e-mail]>; Mon, 18 Aug 2003 08:08:19 -0700 (PDT) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Aug 2003 08:08:15 -0700
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Aug 2003 08:08:15 -0700
Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Aug 2003 08:08:14 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Aug 2003 08:08:15 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Aug 2003 08:08:25 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Aug 2003 08:06:53 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
Thread-Topic: I-D ACTION:draft-deacon-xkms-aia-00.txt
thread-index: AcNjk3viqAAUfr4DRgSnSqOzqZ7fFwCBtFCKAAAGsxQ=
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>, <[e-mail]>
To: Rich Salz <[e-mail]>, "Deacon, Alex" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Date: Mon, 18 Aug 2003 08:07:14 -0700
Message-ID: <9CC764B3-FED1-4E71-8786-08124D2E4AFC@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
X-OriginalArrivalTime: 18 Aug 2003 15:06:53.0811 (UTC) FILETIME=[5BECA430:01C3659A]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<HTML><HEAD><TITLE>RE: I-D ACTION:draft-deacon-xkms-aia-00.txt</TITLE></HEA=
D>
<BODY>
<DIV id=3DidOWAReplyText71735 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Rich - in-line</=
FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Rich Salz<BR><B>Sent:</B> Fri 8/1=
5/2003 6:12 PM<BR><B>To:</B> Deacon, Alex<BR><B>Cc:</B> Ryan M. Hurst; ietf=
[e-mail]; [e-mail]<BR><B>Subject:</B> RE: I-D ACTION:draft-deac=
on-xkms-aia-00.txt<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=3D2>&gt; So the XKMS AIA would simply point to a WSDL file th=
at defines where the</FONT> <BR><FONT size=3D2>&gt; XKMS service lives, wha=
t transport should be used, is a SOAP envelope</FONT> <BR><FONT size=3D2>&g=
t; required, what services are provided and even perhaps even details as to=
</FONT> <BR><FONT size=3D2>&gt; what key identification forms can be sent a=
nd what the trust model is.</FONT> </P>
<P><FONT size=3D2>Uhm, yuck. :)</FONT> </P>
<P><FONT size=3D2>Are you really expecting every XKMS request to start out =
with a</FONT> <BR><FONT size=3D2>GET If-modified-since request?&nbsp; And t=
hen have to parse WSDL to understand</FONT> <BR><FONT size=3D2>what do do?&=
nbsp; Again, every single XKMS request and every single XKMS client?</FONT>=
 </P>
<P><FONT size=3D2>If you don't expect XKMS applications to do the condition=
al GET, then it's</FONT> <BR><FONT size=3D2>not a URL, but is instead a URI=
.&nbsp; At that point, it becomes an identifier</FONT> <BR><FONT size=3D2>f=
or *a particular instance* of a WSDL file defining the service.&nbsp; At th=
at</FONT> <BR><FONT size=3D2>point, you might as following standard AIA pra=
ctice, and let the OID</FONT> <BR><FONT size=3D2>define the service and tra=
nsport, and the value define how to find it.</FONT> </P>
<P><FONT size=3D2>The only profile worth defining is XKMS over SOAP 1.1 and=
 SOAP 1.2,</FONT> <BR><FONT size=3D2>and the value of the OID is a URL of t=
he service that can tell you</FONT> <BR><FONT size=3D2>how to Validate the =
certificate.&nbsp; Mandate "ds:X509Data/ds:X509Certificate"</FONT> <BR><FON=
T size=3D2>MUST be supported, and that other forms MAY be supported.&nbsp; =
Leave it</FONT> <BR><FONT size=3D2>up to WS-I (when they get to us) to prof=
ile what MAYs should become</FONT> <BR><FONT size=3D2>MUSTs.</FONT> </P>
<P>[rmh] I agree, however in the case of a certifcate validation engine I c=
an't imagine a case when anything other that a X509Certificate would be use=
d for key evaluation, but with that being said as long as there is the MUST=
 for support of x509 based identification thats workable.</P>
<P><FONT size=3D2>I think it makes little sense, for example, for a cert to=
</FONT> <BR><FONT size=3D2>say "here's the Register service if you want to =
make more like me." :)</FONT> </P>
<P>[rmh] I agree,&nbsp; my point is that we should be explicit in the draft=
.</P>
<P>&nbsp;</P>
<P><FONT size=3D2>I think Ryan's questions are slightly interesting, but on=
ly if you</FONT> <BR><FONT size=3D2>think a certificate is going to contain=
 multiple AIA's.&nbsp; I don't.</FONT> <BR><FONT size=3D2>In general, his q=
uestions are leading us to the morass of "PKI-ness"</FONT> <BR><FONT size=
=3D2>that has, so far, managed to throttle PKI in its crib.</FONT> </P>
<P>[rmh] I think support for multiple AIAs&nbsp;is important, also these co=
ncepts must be explicit in a PKIX draft like this otherwise existing&nbsp;c=
ertificate validation engines would make a different set&nbsp;of assumtions=
 resulting in non-interoperable deployments.</P>
<P><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /r$</FONT>=
 <BR><FONT size=3D2>--</FONT> <BR><FONT size=3D2>Rich Salz&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; Chief Security Architect</FONT> <BR><FONT size=3D2>DataPower Tec=
hnology&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A href=3D"http://www.datapower=
.com/" target=3D_blank>http://www.datapower.com/</A></FONT> <BR><FONT size=
=3D2>XS40 XML Security Gateway&nbsp; <A href=3D"http://www.datapower.com/pr=
oducts/xs40.html" target=3D_blank>http://www.datapower.com/products/xs40.ht=
ml</A></FONT> <BR><FONT size=3D2>XML Security Overview&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; <A href=3D"http://www.datapower.com/xmldev/xmlsecurity.html" targ=
et=3D_blank>http://www.datapower.com/xmldev/xmlsecurity.html</A></FONT> </P=
></DIV></BODY></HTML>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IF40qt013675 for <[e-mail]>; Mon, 18 Aug 2003 08:04:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IF3xWi013674 for ietf-pkix-bks; Mon, 18 Aug 2003 08:03:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IF3wqt013668 for <[e-mail]>; Mon, 18 Aug 2003 08:03:58 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Aug 2003 08:00:20 -0700
Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Aug 2003 08:00:07 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Aug 2003 08:00:04 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Aug 2003 08:00:17 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Aug 2003 07:58:47 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
MIME-Version: 1.0
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <59EB67E2-1585-4DC5-943A-3B9F2802BB56@mimectl>, <[e-mail]>
To: dan ash <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: I-D ACTION:draft-deacon-xkms-aia-00.txt
Thread-Index: AcNlmWkW/oT2wtA5Qpao0qPDJ2Tbng==
Message-ID: <A538E88C-83D1-4569-9847-211E0577A0D6@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Mon, 18 Aug 2003 08:00:06 -0700
X-OriginalArrivalTime: 18 Aug 2003 14:58:47.0762 (UTC) FILETIME=[3A377320:01C36599]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_A17983A4-6E94-4956-AB55-03F84C998C74_"

--_A17983A4-6E94-4956-AB55-03F84C998C74_
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="iso-8859-1"

Dan - in-line



From: dan ash
Sent: Mon 8/18/2003 7:09 AM
To: Ryan M. Hurst
Cc: [e-mail]; [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt


> 	Should we assume the AIA only points to a XKMS Key Information
> 	service? If so should the OID be labeled as such?

I think it's a safe assuption.  No use of the AIA for the registration
service.  Even further, I can't image the AIA being useful for 'locate'
service.  It should apply to 'validate' only.    =20
[rmh] exactly, but this should be clearly stated in the rfc.

>    3. Shouldn't there be a documented delegated trust model, ala OCSP
> for
> 	XKMS Key Info? Maybe we need a XKMS Key Information EKU and the
> same
>       1 level rule set used in OCSP could be applied. This is=20
> important
> for
> 	clients that are base relying parties and are not knowledgeable
> enough
> 	to operate their own or explicitly choose a third-party to do
> this for
> 	them.

I believe both XKRSS and XKISS ('validate' anyway) require an explicit
relationship to be established with the client beforehand.  And would
include the URL and trust parameters of the service.  This may seem like
a shortcoming of XKMS, but it helps to deliver the level of simplicity
that was desired (at least for the client).  And besides, what other
authentication system allows a relying party to authenticate users
without having prior knowledge or a relationship, directly or indirectly
with the user or their authority.

The usefulness of the AIA is to support indirect relationships, or
through a third party.  The AIA would allow an XKISS service to locate
the authoritative XKISS service for the user in question.   This
functionality would require a trust model such as an EKU for XKISS and so
forth.  But I don't think these type of requirements should be part of
XKMS.  In fact, I think they will covered by WS-policy or something of
the like.   =20

[rmh] Your right, however this "flexability" is not appropriate in a intern=
et model where clients grock PKI and the users do not. Imagine your mom hav=
ing to manualy establish trust to a KISS service before she could buy that =
book she wants. I suggest defining a client profile that says something all=
ong the lines that the x509 key type must be supported and the responses MA=
Y be validated in way X,Y,Z; efectivly ca signed, ca delegated (EKU, 1 leve=
l delegation), or other.
dan ash
-- dan ash [e-mail]-- http://www.fastmail.fm - The professiona=
l email service

--_A17983A4-6E94-4956-AB55-03F84C998C74_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText89908 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Dan - in-line</F=
ONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> dan ash<BR><B>Sent:</B> Mon 8/18/=
2003 7:09 AM<BR><B>To:</B> Ryan M. Hurst<BR><B>Cc:</B> [e-mail]; w=
[e-mail]<BR><B>Subject:</B> RE: I-D ACTION:draft-deacon-xkms-aia-00.t=
xt<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">&gt; 	Should we assume the AIA on=
ly points to a XKMS Key Information
&gt; 	service? If so should the OID be labeled as such?

I think it's a safe assuption.  No use of the AIA for the registration
service.  Even further, I can't image the AIA being useful for 'locate'
service.  It should apply to 'validate' only.    =20
[rmh] exactly, but this should be clearly stated in the rfc.

&gt;    3. Shouldn't there be a documented delegated trust model, ala OCSP
&gt; for
&gt; 	XKMS Key Info? Maybe we need a XKMS Key Information EKU and the
&gt; same
&gt;       1 level rule set used in OCSP could be applied. This is=20
&gt; important
&gt; for
&gt; 	clients that are base relying parties and are not knowledgeable
&gt; enough
&gt; 	to operate their own or explicitly choose a third-party to do
&gt; this for
&gt; 	them.

I believe both XKRSS and XKISS ('validate' anyway) require an explicit
relationship to be established with the client beforehand.  And would
include the URL and trust parameters of the service.  This may seem like
a shortcoming of XKMS, but it helps to deliver the level of simplicity
that was desired (at least for the client).  And besides, what other
authentication system allows a relying party to authenticate users
without having prior knowledge or a relationship, directly or indirectly
with the user or their authority.

The usefulness of the AIA is to support indirect relationships, or
through a third party.  The AIA would allow an XKISS service to locate
the authoritative XKISS service for the user in question.   This
functionality would require a trust model such as an EKU for XKISS and so
forth.  But I don't think these type of requirements should be part of
XKMS.  In fact, I think they will covered by WS-policy or something of
the like.   =20
</PRE><PRE style=3D"WORD-WRAP: break-word">[rmh] Your right, however this "=
flexability" is not appropriate in a internet model where clients grock PKI=
 and the users do not. Imagine your mom having to manualy establish trust t=
o a KISS service before she could buy that book she wants. I suggest defini=
ng a client profile that says something allong the lines that the x509 key =
type must be supported and the responses MAY be validated in way X,Y,Z; efe=
ctivly ca signed, ca delegated (EKU, 1 level delegation), or other.<BR></PR=
E><PRE style=3D"WORD-WRAP: break-word">dan ash</PRE>-- dan ash danielash@fa=
stmail.fm-- http://www.fastmail.fm - The professional email service</DIV></=
BODY></HTML>

--_A17983A4-6E94-4956-AB55-03F84C998C74_--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G1CIqt030483 for <[e-mail]>; Fri, 15 Aug 2003 18:12:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7G1CIAP030482 for ietf-pkix-bks; Fri, 15 Aug 2003 18:12:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.datapower.com (ip67-93-141-188.z141-93-67.customer.algx.net [67.93.141.188]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G1CFqt030476 for <[e-mail]>; Fri, 15 Aug 2003 18:12:16 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 20819 invoked by uid 529); 16 Aug 2003 01:12:18 -0000
Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Aug 2003 01:12:18 -0000
Date: Fri, 15 Aug 2003 21:12:18 -0400 (EDT)
From: Rich Salz <[e-mail]>
To: "Deacon, Alex" <[e-mail]>
cc: "'Ryan M. Hurst'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> So the XKMS AIA would simply point to a WSDL file that defines where the
> XKMS service lives, what transport should be used, is a SOAP envelope
> required, what services are provided and even perhaps even details as to
> what key identification forms can be sent and what the trust model is.

Uhm, yuck. :)

Are you really expecting every XKMS request to start out with a
GET If-modified-since request?  And then have to parse WSDL to understand
what do do?  Again, every single XKMS request and every single XKMS client?

If you don't expect XKMS applications to do the conditional GET, then it's
not a URL, but is instead a URI.  At that point, it becomes an identifier
for *a particular instance* of a WSDL file defining the service.  At that
point, you might as following standard AIA practice, and let the OID
define the service and transport, and the value define how to find it.

The only profile worth defining is XKMS over SOAP 1.1 and SOAP 1.2,
and the value of the OID is a URL of the service that can tell you
how to Validate the certificate.  Mandate "ds:X509Data/ds:X509Certificate"
MUST be supported, and that other forms MAY be supported.  Leave it
up to WS-I (when they get to us) to profile what MAYs should become
MUSTs.

I think it makes little sense, for example, for a cert to
say "here's the Register service if you want to make more like me." :)

I think Ryan's questions are slightly interesting, but only if you
think a certificate is going to contain multiple AIA's.  I don't.
In general, his questions are leading us to the morass of "PKI-ness"
that has, so far, managed to throttle PKI in its crib.
        /r$
--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G0kqqt029453 for <[e-mail]>; Fri, 15 Aug 2003 17:46:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7G0kqGO029452 for ietf-pkix-bks; Fri, 15 Aug 2003 17:46:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G0kpqt029443 for <[e-mail]>; Fri, 15 Aug 2003 17:46:51 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Aug 2003 17:44:26 -0700
Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Aug 2003 17:44:21 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Aug 2003 17:44:46 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Aug 2003 17:44:26 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Aug 2003 17:44:26 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.150 157.54.0.150 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.150 157.54.0.150 from 157.54.1.70 157.54.1.70 via HTTP with MS-WebStorage 6.5.6944
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
To: "Deacon, Alex" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: I-D ACTION:draft-deacon-xkms-aia-00.txt
Thread-Index: AcNjj40zpbXiCqsdQ2eOOogHTQEGTw==
Message-ID: <59EB67E2-1585-4DC5-943A-3B9F2802BB56@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Fri, 15 Aug 2003 17:44:29 -0700
X-OriginalArrivalTime: 16 Aug 2003 00:44:26.0447 (UTC) FILETIME=[8B4405F0:01C3638F]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_7C8D9E93-D216-4713-A007-72644C934DBD_"

--_7C8D9E93-D216-4713-A007-72644C934DBD_
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thats a resonable approach, however I hate the idea of multiple connections=
; e.g. I think it would be better to say its allways a HTTP POST or similar=
; from a client standpoint you get to share 15 seconds or so for the entire=
 validation process, the more wire retrievals you have the worse off you ar=
e :)

Ryan



From: Deacon, Alex
Sent: Fri 8/15/2003 5:09 PM
To: 'Ryan M. Hurst'; Deacon, Alex
Cc: [e-mail]; [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt


Hi Ryan,

Thanks for the comments.  I agree that we need to address all of the issues
you raise.  However upon thinking about the best way to address them it
seems to me that instead of defining XKMS profiles and the like, which may
not be an easy task (i.e. rat hole), we should probably just use WSDL to
define what is and what is not supported.  =20

So the XKMS AIA would simply point to a WSDL file that defines where the
XKMS service lives, what transport should be used, is a SOAP envelope
required, what services are provided and even perhaps even details as to
what key identification forms can be sent and what the trust model is.=20

Comments?

Alex


> -----Original Message-----
> From: Ryan M. Hurst [mailto:[e-mail]]
> Sent: Monday, August 04, 2003 11:08 AM
> To: Deacon, Alex
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
>=20
>=20
>=20
> Alex - Glad to see some one has put together a story for how=20
> this can be
> represented in the X.509 world. I have a couple comments/questions
> though,
>=20
>    1. XKMS supports several different services (key=20
> information and key
>       Registration) and implementations will likely only support a
> profile
>       of each.
>      =20
> 	Should we assume the AIA only points to a XKMS Key Information
> 	service? If so should the OID be labeled as such?
>=20
>       Should there be a PKIX profile of what a server=20
> supports when this
>       OID is present in the AIA? For example what forms of key
> 	Identification are supported, I assume if it's being referred to
> in a
>       X.509 certificate it would minimally support the X.509 key
> 	identification form. What about the types of information that is
> 	available?
>=20
>    2. XKMS may used in a variety of protocols, shouldn't the draft
> indicate which transport that should be assumed in PKIX environments?=20
>=20
> 	Is it assumed that this is just a post of a XKMS request, if so
> is
> 	There a need for an application mime-type? Is it assumed it will
> be
> 	Wrapped in a SOAP envelop and be routed based on that?
>=20
>    3. Shouldn't there be a documented delegated trust model, ala OCSP
> for
> 	XKMS Key Info? Maybe we need a XKMS Key Information EKU and the
> same
>       1 level rule set used in OCSP could be applied. This is=20
> important
> for
> 	clients that are base relying parties and are not knowledgeable
> enough
> 	to operate their own or explicitly choose a third-party to do
> this for
> 	them.
>=20
> I have to admit I am not a XKMS pro, so some of these questions may
> sound out of place but they were the first ones to come to mind when I
> saw this.
>=20
> Ryan M. Hurst
>=20
>=20
>=20
> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]]
> On Behalf Of [e-mail]
> Sent: Monday, August 04, 2003 7:14 AM
> Cc: [e-mail]
> Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>=20
>=20
> 	Title		: AIA Access Method for XKMS Services
> 	Author(s)	: A. Deacon
> 	Filename	: draft-deacon-xkms-aia-00.txt
> 	Pages		: 5
> 	Date		: 2003-8-4
> =09
> Authority Information Access extension that is used to indicate how
> to access CA information and services for the issuer of the
> certificate in which this extension appears.  This document defines
> an access method identifier that indicates the location of XKMS
> [XKMS] services.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-deacon-xkms-aia-00.txt
>=20
> To remove yourself from the IETF Announcement list, send a message to=20
> ietf-announce-request with the word unsubscribe in the body of the
> message.
>=20
> 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-deacon-xkms-aia-00.txt".
>=20
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html=20
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-deacon-xkms-aia-00.txt".
> =09
> 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.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20
>=20

--_7C8D9E93-D216-4713-A007-72644C934DBD_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText37206 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Thats a resonabl=
e approach, however I hate the idea of multiple connections; e.g. I think i=
t would be better to say its allways a HTTP POST or similar; from a client =
standpoint you get to share 15 seconds or so for the entire validation proc=
ess, the more wire retrievals you have the worse off you are :)</FONT></DIV=
>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Deacon, Alex<BR><B>Sent:</B> Fri =
8/15/2003 5:09 PM<BR><B>To:</B> 'Ryan M. Hurst'; Deacon, Alex<BR><B>Cc:</B>=
 [e-mail]; [e-mail]<BR><B>Subject:</B> RE: I-D ACTION:draft=
-deacon-xkms-aia-00.txt<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">Hi Ryan,

Thanks for the comments.  I agree that we need to address all of the issues
you raise.  However upon thinking about the best way to address them it
seems to me that instead of defining XKMS profiles and the like, which may
not be an easy task (i.e. rat hole), we should probably just use WSDL to
define what is and what is not supported.  =20

So the XKMS AIA would simply point to a WSDL file that defines where the
XKMS service lives, what transport should be used, is a SOAP envelope
required, what services are provided and even perhaps even details as to
what key identification forms can be sent and what the trust model is.=20

Comments?

Alex


&gt; -----Original Message-----
&gt; From: Ryan M. Hurst [mailto:[e-mail]]
&gt; Sent: Monday, August 04, 2003 11:08 AM
&gt; To: Deacon, Alex
&gt; Cc: [e-mail]
&gt; Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
&gt;=20
&gt;=20
&gt;=20
&gt; Alex - Glad to see some one has put together a story for how=20
&gt; this can be
&gt; represented in the X.509 world. I have a couple comments/questions
&gt; though,
&gt;=20
&gt;    1. XKMS supports several different services (key=20
&gt; information and key
&gt;       Registration) and implementations will likely only support a
&gt; profile
&gt;       of each.
&gt;      =20
&gt; 	Should we assume the AIA only points to a XKMS Key Information
&gt; 	service? If so should the OID be labeled as such?
&gt;=20
&gt;       Should there be a PKIX profile of what a server=20
&gt; supports when this
&gt;       OID is present in the AIA? For example what forms of key
&gt; 	Identification are supported, I assume if it's being referred to
&gt; in a
&gt;       X.509 certificate it would minimally support the X.509 key
&gt; 	identification form. What about the types of information that is
&gt; 	available?
&gt;=20
&gt;    2. XKMS may used in a variety of protocols, shouldn't the draft
&gt; indicate which transport that should be assumed in PKIX environments?=
=20
&gt;=20
&gt; 	Is it assumed that this is just a post of a XKMS request, if so
&gt; is
&gt; 	There a need for an application mime-type? Is it assumed it will
&gt; be
&gt; 	Wrapped in a SOAP envelop and be routed based on that?
&gt;=20
&gt;    3. Shouldn't there be a documented delegated trust model, ala OCSP
&gt; for
&gt; 	XKMS Key Info? Maybe we need a XKMS Key Information EKU and the
&gt; same
&gt;       1 level rule set used in OCSP could be applied. This is=20
&gt; important
&gt; for
&gt; 	clients that are base relying parties and are not knowledgeable
&gt; enough
&gt; 	to operate their own or explicitly choose a third-party to do
&gt; this for
&gt; 	them.
&gt;=20
&gt; I have to admit I am not a XKMS pro, so some of these questions may
&gt; sound out of place but they were the first ones to come to mind when I
&gt; saw this.
&gt;=20
&gt; Ryan M. Hurst
&gt;=20
&gt;=20
&gt;=20
&gt; -----Original Message-----
&gt; From: [e-mail]=20
&gt; [mailto:[e-mail]]
&gt; On Behalf Of [e-mail]
&gt; Sent: Monday, August 04, 2003 7:14 AM
&gt; Cc: [e-mail]
&gt; Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt
&gt;=20
&gt; A New Internet-Draft is available from the on-line Internet-Drafts
&gt; directories.
&gt;=20
&gt;=20
&gt; 	Title		: AIA Access Method for XKMS Services
&gt; 	Author(s)	: A. Deacon
&gt; 	Filename	: draft-deacon-xkms-aia-00.txt
&gt; 	Pages		: 5
&gt; 	Date		: 2003-8-4
&gt; =09
&gt; Authority Information Access extension that is used to indicate how
&gt; to access CA information and services for the issuer of the
&gt; certificate in which this extension appears.  This document defines
&gt; an access method identifier that indicates the location of XKMS
&gt; [XKMS] services.
&gt;=20
&gt; A URL for this Internet-Draft is:
&gt; http://www.ietf.org/internet-drafts/draft-deacon-xkms-aia-00.txt
&gt;=20
&gt; To remove yourself from the IETF Announcement list, send a message to=
=20
&gt; ietf-announce-request with the word unsubscribe in the body of the
&gt; message.
&gt;=20
&gt; Internet-Drafts are also available by anonymous FTP. Login with the
&gt; username
&gt; "anonymous" and a password of your e-mail address. After logging in,
&gt; type "cd internet-drafts" and then
&gt; 	"get draft-deacon-xkms-aia-00.txt".
&gt;=20
&gt; A list of Internet-Drafts directories can be found in
&gt; http://www.ietf.org/shadow.html=20
&gt; or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
&gt;=20
&gt;=20
&gt; Internet-Drafts can also be obtained by e-mail.
&gt;=20
&gt; Send a message to:
&gt; 	[e-mail].
&gt; In the body type:
&gt; 	"FILE /internet-drafts/draft-deacon-xkms-aia-00.txt".
&gt; =09
&gt; NOTE:	The mail server at ietf.org can return the document in
&gt; 	MIME-encoded form by using the "mpack" utility.  To use this
&gt; 	feature, insert the command "ENCODING mime" before the "FILE"
&gt; 	command.  To decode the response(s), you will need "munpack" or
&gt; 	a MIME-compliant mail reader.  Different MIME-compliant mail
&gt; readers
&gt; 	exhibit different behavior, especially when dealing with
&gt; 	"multipart" MIME messages (i.e. documents which have been split
&gt; 	up into multiple messages), so check your local documentation on
&gt; 	how to manipulate these messages.
&gt; 	=09
&gt; 	=09
&gt; Below is the data which will enable a MIME compliant mail reader
&gt; implementation to automatically retrieve the ASCII version of the
&gt; Internet-Draft.
&gt;=20
&gt;=20
</PRE></DIV></BODY></HTML>

--_7C8D9E93-D216-4713-A007-72644C934DBD_--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G09Nqt027558 for <[e-mail]>; Fri, 15 Aug 2003 17:09:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7G09NiL027557 for ietf-pkix-bks; Fri, 15 Aug 2003 17:09:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7G09Mqt027552 for <[e-mail]>; Fri, 15 Aug 2003 17:09:22 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h7G09PUh011227; Fri, 15 Aug 2003 17:09:25 -0700 (PDT)
Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <Q0M3ADMC>; Fri, 15 Aug 2003 17:09:25 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, "Deacon, Alex" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
Date: Fri, 15 Aug 2003 17:09:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Ryan,

Thanks for the comments.  I agree that we need to address all of the issues
you raise.  However upon thinking about the best way to address them it
seems to me that instead of defining XKMS profiles and the like, which may
not be an easy task (i.e. rat hole), we should probably just use WSDL to
define what is and what is not supported.   

So the XKMS AIA would simply point to a WSDL file that defines where the
XKMS service lives, what transport should be used, is a SOAP envelope
required, what services are provided and even perhaps even details as to
what key identification forms can be sent and what the trust model is. 

Comments?

Alex


> -----Original Message-----
> From: Ryan M. Hurst [mailto:[e-mail]]
> Sent: Monday, August 04, 2003 11:08 AM
> To: Deacon, Alex
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
> 
> 
> 
> Alex - Glad to see some one has put together a story for how 
> this can be
> represented in the X.509 world. I have a couple comments/questions
> though,
> 
>    1. XKMS supports several different services (key 
> information and key
>       Registration) and implementations will likely only support a
> profile
>       of each.
>       
> 	Should we assume the AIA only points to a XKMS Key Information
> 	service? If so should the OID be labeled as such?
> 
>       Should there be a PKIX profile of what a server 
> supports when this
>       OID is present in the AIA? For example what forms of key
> 	Identification are supported, I assume if it's being referred to
> in a
>       X.509 certificate it would minimally support the X.509 key
> 	identification form. What about the types of information that is
> 	available?
> 
>    2. XKMS may used in a variety of protocols, shouldn't the draft
> indicate which transport that should be assumed in PKIX environments? 
> 
> 	Is it assumed that this is just a post of a XKMS request, if so
> is
> 	There a need for an application mime-type? Is it assumed it will
> be
> 	Wrapped in a SOAP envelop and be routed based on that?
> 
>    3. Shouldn't there be a documented delegated trust model, ala OCSP
> for
> 	XKMS Key Info? Maybe we need a XKMS Key Information EKU and the
> same
>       1 level rule set used in OCSP could be applied. This is 
> important
> for
> 	clients that are base relying parties and are not knowledgeable
> enough
> 	to operate their own or explicitly choose a third-party to do
> this for
> 	them.
> 
> I have to admit I am not a XKMS pro, so some of these questions may
> sound out of place but they were the first ones to come to mind when I
> saw this.
> 
> Ryan M. Hurst
> 
> 
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of [e-mail]
> Sent: Monday, August 04, 2003 7:14 AM
> Cc: [e-mail]
> Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: AIA Access Method for XKMS Services
> 	Author(s)	: A. Deacon
> 	Filename	: draft-deacon-xkms-aia-00.txt
> 	Pages		: 5
> 	Date		: 2003-8-4
> 	
> Authority Information Access extension that is used to indicate how
> to access CA information and services for the issuer of the
> certificate in which this extension appears.  This document defines
> an access method identifier that indicates the location of XKMS
> [XKMS] services.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-deacon-xkms-aia-00.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-deacon-xkms-aia-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-deacon-xkms-aia-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ELxVqt021101 for <[e-mail]>; Thu, 14 Aug 2003 14:59:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ELxVlp021100 for ietf-pkix-bks; Thu, 14 Aug 2003 14:59:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ELxUqt021094 for <[e-mail]>; Thu, 14 Aug 2003 14:59:30 -0700 (PDT) (envelope-from [e-mail])
Received: from wmcooper (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h7ELxVGD006709; Thu, 14 Aug 2003 17:59:31 -0400
From: "Matt Cooper" <[e-mail]>
To: "'Masaki SHIMAOKA'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 14 Aug 2003 17:59:26 -0400
Message-ID: <008201c362af$57656ed0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7ELxUqt021095
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Masaki,

> 1. path building over http
> 
> This text gives an example as path building algorithm based 
> over LDAP. Shall we consider also about a path building 
> algorithm over http? 

Well, it was our intent, though I think perhaps we ended up rather LDAP
centric, to try to remove the retrieval methods from the doc as much as
possible. Problem is, we could write a whole RFC on retrieval alone. In
fact, as I mentioned at the conference, I think that might not be a bad
idea. On the premise of not addresses retrieval methodology in detail, I
don't want to include examples of how to build paths with different
protocols, AIA, LDAP, etc. I think this will make an already long doc much
too long. 

> 2. forward direction vs. reverse direction
> 
> My basic opinion is shown below as hybrid path building.
> =====
> Path building in the forward direction is very useful for 
> tree topology that each node has unique parent. However, when 
> each node has plural parent (e.g., mesh PKI or bi-lateral 
> cross-certified PKI), this method is useful only a bit. 

Can you explain further why you say this? When I look at the problem, the
decision tree in reverse usually appears to be much larger than in forward.
Take a look at the examples of the forward and reverse decision trees in the
ID. From what I can see, and perhaps I'm missing some of the finer points,
reverse is really only more useful in the event the forward (toThisCA) cross
certs are not populated or available. In addition, once you throw a dozen or
more trust roots into the picture, reverse becomes a real mess in my opinion
as you may have to build from all of them.

> First, therefore, a builder SHOULD attempt to build a path in 
> the forward direction till a self-signed certificate (or 
> maybe intermediate certificate issued by plural CAs). Then, 
> the builder MAY attempt to build the remain path either way.

This, or some hybrid of this, is a fine idea, in the abstract at least. I
found that implementation was a bit of a disaster. How do you know that the
partial path you built will necessarily intersect what you build in reverse?
For example, you could build the forward path you to CA "A" that has
multiple certs and then build all possible reverse paths while never finding
the target and also never intersecting A. On the other hand, if you had
simply continued in the forward direction, you might or might not have found
your trust root.

For the last path building module I wrote, it was necessary to interoperate
with PKIs in which the forward elements are not available, so reverse
building was necessary. Initially, we wanted to try both directions
simultaneously, but soon realized that the only way to do this effectively
was to keep the entire graph in memory and traverse all possibilities in
both directions from both sides until a path was found, checking for
intersections at all endpoints at every iteration. Needless to say, this
idea was discarded.

What I ended up implementing was an exhaustive search in the forward
direction, all the while caching all the certs I found along the way. If
path building failed, the path builder then turned around and tried it in
reverse. Since all the reverse elements were cached as well, network traffic
was kept pretty minimal to non-existent unless reverse building opened a new
branch in the tree.

> 3. Static path vs. Dynamic path
> Static certification path means that the client is given 
> beforehand all certificates and all revocation information 
> required for path validation.

This works fine if we trust the same root. But not at all, and in fact can
lead me in the wrong direction, if we don't. I personally don't believe that
any software should be constructed to depend on being supplied the full
path. It is completely debilitating if and when interoperability with other
PKIs is desired through cross certification. In my opinion, path building
should always be done, even if it is only from a local cache + the certs
supplied as the static path. In any event, the aim of the ID is building; if
you only accept static paths, there's nothing to do but validate it.

Best Regards,
Matt Cooper


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Masaki SHIMAOKA
> Sent: Tuesday, July 22, 2003 11:12 PM
> To: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
> 
> 
> 
> Dear Cooper,
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories. This draft is a work item of the Public-Key 
> > Infrastructure (X.509) Working Group of the IETF.
> > 
> > 	Title		: Internet X.509 Public Key 
> Infrastructure:       
> >                           Certification Path Building
> > 	Author(s)	: M. Cooper, Y. Dzambasow
> > 	Filename	: draft-ietf-pkix-certpathbuild-00.txt
> > 	Pages		: 59
> > 	Date		: 2003-7-3
> 
> This is an excellent trial.
> 
> Sorry for my delayed comments below.
> 
> 1. path building over http
> 
> This text gives an example as path building algorithm based 
> over LDAP. Shall we consider also about a path building 
> algorithm over http? # I know and agree that  basically path 
> building is used in the environment which have directory 
> system. IMHO, path building over http may be achieved using 
> cAIssuers accessMethod in AIA extension, but it only 
> describes single path like strict hierarchy.
> 
> 
> 2. forward direction vs. reverse direction
> 
> My basic opinion is shown below as hybrid path building.
> =====
> Path building in the forward direction is very useful for 
> tree topology that each node has unique parent. However, when 
> each node has plural parent (e.g., mesh PKI or bi-lateral 
> cross-certified PKI), this method is useful only a bit. 
> First, therefore, a builder SHOULD attempt to build a path in 
> the forward direction till a self-signed certificate (or 
> maybe intermediate certificate issued by plural CAs). Then, 
> the builder MAY attempt to build the remain path either way.
> 
> 
>         2) Path building by the reverse direction
>         ----------------------------------------->
>    +---------+     +--------------+      +-------------+   
>    | Trusted |     | Intermediate |      | Self-Signed |   
>    |  Root   |---->|  Certificate |----->| Certificate |   ^
>    +---------+     +--------------+      +-------------+   |
>                                                 |          |
>                                                 |          |
>                                                 v          |
>                                         +----------------+ | 1) Path
>                                         |  Intermediate  | | building
>                                         | Certificate(*) | |    by
>                                         +----------------+ |  forward 
>                                                  |         | direction
>                                                  |         |
>                                                  v         |
>                                          +--------------+  |
>                                          |     Target   |  |
>                                          |  Certificate |   
>                                          +--------------+   
>         (*) Not self-signed certificate.
> # I know more consideration yet is required for this.
> =====
> 
> And this topic has one problem.
> Some subordinate CA populate their CA certificate to 
> issuedToThisCA of crossCertificatePair attribute in their own 
> (CA) directory entry. On the other hand, most cross-certified 
> (not subordinate) CA also populates their cross-certificate 
> to same location. When a path builder attempts hybrid 
> building as above, the builder in second step (reverse 
> direction) does not require obtaining the subordinate CA information.
> 
> 
> In almost (hierarchical) PKI, path building may finish before 
> second step. Only in some complex PKI, path building may need 
> second step. Anyway, this hybrid algorithm is useful for 
> every PKI, I think.
> 
> 
> 3. Static path vs. Dynamic path
> Static certification path means that the client is given 
> beforehand all certificates and all revocation information 
> required for path validation. On the other hand, dynamic 
> certification path means that the client at least must obtain 
> some certificates and revocation information required for 
> path validation. Dynamic certification path may use some 
> certificates and revocation information in certificate store 
> or local cache. For a client that cannot build a 
> certification path dynamically, we should consider static 
> certification path, e.g., SSL/TLS handshake.
> 
> 
> Your I-D describes that how build a certification path, and 
> my 'memo for mPKI' I-D aims to support how to design a 
> certification path. So I hope to review our documents each 
> other frequently.
> 
> Best Regards,
> -----
> Masaki SHIMAOKA
> 
> SECOM Trust.net
> System Engineering Dpt.
> Tel: [phone] (ext.3551)
> Fax: [phone]
> e-mail: [e-mail]
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJWrqt015016 for <[e-mail]>; Thu, 14 Aug 2003 12:32:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EJWreT015014 for ietf-pkix-bks; Thu, 14 Aug 2003 12:32:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJWnqt015009 for <[e-mail]>; Thu, 14 Aug 2003 12:32:49 -0700 (PDT) (envelope-from [e-mail])
Received: from wmcooper (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h7EJWSGD022500; Thu, 14 Aug 2003 15:32:29 -0400
From: "Matt Cooper" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'Steve Hanna'" <[e-mail]>, "'PKIX List'" <[e-mail]>, "'Peter Hesse'" <[e-mail]>, "'Yuriy Dzambasow'" <[e-mail]>, "'Susan Joseph'" <[e-mail]>, "'Richard E. Nicholas \(Nicholas, Richard\)'" <[e-mail]>
Subject: RE: draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 14 Aug 2003 15:32:23 -0400
Message-ID: <005401c3629a$d4ff1b80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7EJWoqt015010
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Denis,

First, apologies for taking so long to get you a reply.

You're right, the topic of retrieval (where to find certificates,
discussions of various sources, how to obtain revocation information, and
what CAs should put in certs to facilitate all of this) is a very important
topic that is intimately related to path building. However, I think that
they are separable topics. Our document shies away from retrieval topics and
focuses on ideas for how to go about navigating the decision tree once you
have the certificates. (Perhaps we have put the cart before horse!?) On the
other hand, we didn't feel that we could address the topic of building
without some limited discussion on retrieval. (Hence the rather short
sections you referred to.)

I agree with you 110% that additional guidance for both PKI consumers and
CAs in this area would be very helpful. BUT, in the interest of keeping the
document from growing out of control, I submit that retrieval would be an
ideal topic for a new document. (In fact, this idea was brought up at the
meeting in Vienna.) Items A-C in your message would be ideal content for
such a document. What do you (and others) think of this idea?

> From: Denis Pinkas
> 1. The difference between a CA-certificate and a cross-certificate is 
> still very hazy since what means a "realm" is either left undefined or 
> is said to be "dependant upon local policy". It is thus impossible to 
> have standard rules with such an approach.

I assume you referring to the sorting method that suggests you traverse
certs from cACertificate prior to crossCertificatePair? This is based solely
on what we've seen in the field as common practice. So, although realm is a
fuzzy notion, more often than not (from what I've seen at least) it seems
that if both cACertificate and crossCertificatePair are populated, that
cACertificate is the "local realm" and usually confines searches to the
local network. But, like all the other sorting methods, it won't work all
the time for every scenario. I personally like this sorting method, but
there are other dissenters. I certainly wouldn't oppose removal if that
seems to be the consensus or the group feels it won't contribute to
optimizing the path building.

> From: Denis Pinkas
> Is it really important to make the difference if both:
> 
>   - the pointers to CA repositories are present, and
>   - these repositories entries are correctly filled-in ?

I think so. Retrieving the certs is only half the problem - these pointers
help you find certs, but they don't necessarily help you decide what to do
with them once you have them. If we can use some information to guess at
whether the CA is local to the PKI consumer vs. remote, we can use this to
try to consume paths from the local (and presumably faster) network first.
Were you looking for a statement that says use of these sources should
over-ride other available sources?

> From: Denis Pinkas
> Figure 3 does not make sense unless the trust points
> are indicated.

Is it necessary for the diagram to indicate which CA (if any of them) is the
trust point? On the other hand, to make it consistent with the other
examples, I agree there should be one designated. The other thing I don't
like about this diagram is that it needs to be 4 or 5 CAs instead of three -
3 CAs looks just like a ring topology. I  will change this in the next
version.

> From: Denis Pinkas
> 3. The case of validating a certificate in the past after a CA key 
> rollover (using the new root key) should be addressed.

Do you mean validating an old certificate at some past T where T precedes
the notBefore in the cert issued from the new CA key to the old CA key? I
don't think this should validate. Then on the other side of the notBefore,
no additional discussion should be necessary, or am I missing what you are
telling me? I think the current sorting methods will handle key-rollover for
a T post the notBefore time without a problem.

> From: Denis Pinkas
> 4. An interesting case to discuss would be the encoding of the issuer 
> name before and after December 31, 2003 since all certificates issued 
> after December 31, 2003 MUST use the UTF8String encoding of 
> DirectoryString (except as noted). The case of "name rollover" 
> certificates to support an orderly migration to UTF8String encoding 
> should be explained.

Excellent idea and thanks for pointing it out. Although, I think we should
not use  MUST here since this is informational only.

> From: Denis Pinkas
> 5. The document is far too long.

Denis, you told me this immediately following a bunch of suggestions on how
to make it longer! To tell you the truth, I agree, it is rather lengthy. On
the other hand, I would be reticent to remove any of the sorting discussion.
And, I think absent a retrieval doc, there needs to be at least some limited
discussion of retrieval. I'm not certain how to shorten it without removing
something that others may well find to be of value. Perhaps the sorting
methods could be moved to an appendix?

-Matt

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Tuesday, July 15, 2003 5:23 AM
> To: Peter Hesse; 'Matt Cooper'; 'Yuriy Dzambasow'; 'Susan 
> Joseph'; Richard E. Nicholas (Nicholas, Richard)
> Cc: Steve Hanna; 'PKIX List'
> Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
> 
> 
> Comments on certpathbuild-00.txt
> 
> The title of the document was promising, but the content is 
> not exactly what 
> would have been expected.
> 
> The topic should be how to allow interoperability to find out 
> the elements 
> (i.e. both the certificates and the associated revocation status 
> information) needed for to build a certification path either walking 
> downwards or upwards the certification tree.
> 
> The document should explain how inserting some of the 
> extensions defined in 
> RFC 3280 will allow to build the certification path, 
> irrespective of local 
> conditions (e.g. the user does not have a XX-xxxxxxDirectory where 
> everything needed is stored. :-)  )
> 
> Some interesting elements are provided starting page 54, in 
> sections 6.2 and 
> 6.3. but this is far from sufficient.
> 
> There are two solutions to this problem, either walking 
> downwards or upwards 
> the certification tree.
> 
> 
> A. Walking downwards the certification tree.
> 
> Each trust point SHOULD include in the self-signed 
> certificate the way to 
> find out where the CA has placed the CA certificates that it 
> issues. This 
> SHALL be done using the Subject Information Access extension 
> defined in 
> section 4.2.2.2 from RFC 3280.
> 
> The id-ad-caRepository OID SHALL be used to indicate in which 
> repository the 
> CA publishes its certificates and CRLs (if issued).
> 
> Each CA certificate SHOULD also include the Subject 
> Information Access 
> extension defined in section 4.2.2.2. from RFC 3280.
> 
> This is the preferred method, since anyway trust points MUST be known.
> 
> 
> B. Walking upwards the certification tree.
> 
> Each end-entity certificate and each CA certificate SHOULD 
> include the way 
> to find out where the CA is placing the other certificates. 
> This SHALL be 
> done using the Authority Information Access extension defined 
> in section 
> 4.2.2.1 from RFC 3280 :
> 
> The id-ad-caIssuers OID SHALL be used to list where the CA 
> that has issued 
> the certificate lists CA certificates issued to the CA.
> 
> This extension SHOULD be included in end-entity certificates and CA 
> certificates.
> 
> This can only be a complement to the previous method, since 
> anyway trust 
> points MUST be known. When the downwards approach does not 
> succeed (explain 
> in which cases, it may not succeed), then a combination of 
> both methods may 
> succeed.
> 
> Note: The location of CRLs is not specified in this extension. That 
> information is provided by the cRLDistributionPoints extension.
> 
> 
> C. Revocation checking
> 
> For revocation checking each end-entity and CA certificate 
> SHALL either 
> include :
> 
>     a) a cRLDistributionPoints extension, or
>     b) Subject Information access extension that includes the 
> id-ad-ocsp OID
>        to indicate the location of servers using the Online 
> Certificate
>        Status Protocol (OCSP) [RFC 2560].
> 
> 
> Other comments.
> 
> 1. The difference between a CA-certificate and a 
> cross-certificate is still 
> very hazy since what means a "realm" is either left undefined 
> or is said to 
> be "dependant upon local policy". It is thus impossible to 
> have standard 
> rules with such an approach.
> 
> Introducing naming constraints between subject and issuer 
> names might be 
> more appropriate; however, the real question is the following:
> 
> Is it really important to make the difference if both:
> 
>   - the pointers to CA repositories are present, and
>   - these repositories entries are correctly filled-in ?
> 
> 
> 2. There is, as usual, some confusion between cross 
> certification (which is, 
> by definition, unilateral) and mutual cross certification 
> (see section 
> 13.2). Figure 3 does not make sense unless the trust points 
> are indicated.
> 
> 
> 3. The case of validating a certificate in the past after a 
> CA key rollover 
> (using the new root key) should be addressed.
> 
> 
> 4. An interesting case to discuss would be the encoding of 
> the issuer name 
> before and after December 31, 2003 since all certificates 
> issued after 
> December 31, 2003 MUST use the UTF8String encoding of DirectoryString 
> (except as noted). The case of "name rollover" certificates 
> to support an 
> orderly migration to UTF8String encoding should be explained .
> 
> 
> 5. The document is far too long.
> 
> 
> Denis
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DHFlqt000185 for <[e-mail]>; Wed, 13 Aug 2003 10:15:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DHFlFk000184 for ietf-pkix-bks; Wed, 13 Aug 2003 10:15:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DHFjqt000161 for <[e-mail]>; Wed, 13 Aug 2003 10:15:45 -0700 (PDT)
Received: from above.proper.com (above.proper.com [208.184.76.39]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 8871E206609 for <[e-mail]>; Wed, 13 Aug 2003 13:14:14 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGPiqt096709 for <[e-mail]>; Wed, 13 Aug 2003 09:25:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DGPiTe096708 for ietf-pkix-bks; Wed, 13 Aug 2003 09:25:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGPgqt096700 for <[e-mail]>; Wed, 13 Aug 2003 09:25:42 -0700 (PDT)
Received: from above.proper.com (above.proper.com [208.184.76.39]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 479F8206607 for <[e-mail]>; Wed, 13 Aug 2003 12:24:10 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DFMVqt090446 for <[e-mail]>; Wed, 13 Aug 2003 08:22:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DFMVce090445 for ietf-pkix-bks; Wed, 13 Aug 2003 08:22:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DFMTqt090426 for <[e-mail]>; Wed, 13 Aug 2003 08:22:29 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (92.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.92]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003081315222211300cv2b9e>; Wed, 13 Aug 2003 15:22:23 +0000
Message-ID: <007501c361ae$b1f827e0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gietz" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <p05210604bb4eed81d497@[128.89.89.75]> <00f201c357c7$dfc95d10$020aff0a@tsg1> <p05210600bb501fcc5896@[128.89.89.75]> <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Wed, 13 Aug 2003 08:05:43 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

it is peter and your comments are dead on.

Todd
----- Original Message ----- 
From: "Peter Gietz" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "todd glassey" <[e-mail]>; "Peter Gutmann"
<[e-mail]>; <[e-mail]>
Sent: Wednesday, August 13, 2003 3:21 AM
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)


I am not really sure on what layer this thread is being discussed, but
my feeling is that it is rather on business and political layers than on
a technical one.

Multi-valued RDNs are not very complicated to support, basically it is
one more loop when analysing a DN added to the loop for the single
RDN-components of the DN. having found a RDN, you just loop once more to
find the single parts of a possibly multi-valued RDN. This can be
implemented within one day in any implementation. Most LDAP libraries
have a function called explode_RDN or similiar that helps you with this
additional loop.

There must be other reasons for not wanting to implement that, and I
suspect these reasons have more to do with interests in being not 100%
compliant to a standard.

BTW: The LDAP standard is very clear about the issue. RFC 2253 says:

> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
 >
>        RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
>         AttributeTypeAndValue
>
>        AttributeTypeAndValue ::= SEQUENCE {
>         type  AttributeType,
>         value AttributeValue }
[...]

> Where there is a multi-valued RDN, the outputs from adjoining
>    AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
>    character.

RFC 3280 uses exactly the same definition:

> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
>
>    RelativeDistinguishedName ::=
>      SET OF AttributeTypeAndValue
>
>    AttributeTypeAndValue ::= SEQUENCE {
>      type     AttributeType,
>      value    AttributeValue }


Very clear, very easy to implement, so what is all the fuzz about?

IETF standardization as other standardization activities is about
interoperability. People believing in such, should at least try to
implement the standards. There might be features that are too costly to
implement and I would understand discussions like this thread. In this
case the only point worth while mentioning is that Microsoft is not
implementing multi-valued RDNs and may be to ask representatives of that
company why they don't. In our X.509 certificate schema draft we do
acknowledge the fact, by specifying an alternative Name Form
(X.509issuerSerial), which BTW was not my idea. But reality check
shouldn't go further by saying "if company X (and may be one or two
others) don't support this, nobody should do it". This is not the IETF
spirit. And I am very fine with WG chairs that refuse to go along these
lines.

Cheers,

Peter

Stephen Kent wrote:

>
> At 17:56 -0700 7/31/03, todd glassey wrote:
>
>> Stephen this is the fundamental failing of the IESG to not 'slap you
>> silly'
>> for this... But you nor any other WG Chair were empowered to make your
>> WG a
>> fiefdom, so it is not for you to say what is and is not a standard nor
>> is it
>> appropriate for you to make any value judgments as a WG chair as to
>> what the
>> IETF is all about. That is for its members to decide and as a member
>> you get
>> one and only one vote... and as a WG Chair you get NO votes.
>
>
> As usual, you misunderstand.  The IETF is defined by its membership, and
> it empowers WG chairs, the IESG and the IAB to make value judgements. If
> the value judgements are seen to be inappropriate, there are appeal
> processes available to the parties who think they have been wronged.
> This is true of other standards bodies as well. Your notion of how a
> standards body should operate is NOT accepted or practiced by any of
> standards bodies with which I am familiar, e.g., ANSI, ITU, ETSI, IEEE,
> ...  Because we don't formally vote on matters, WG chairs also are
> empowered to decide when WG consensus is achieved.  IESG members must
> agree on whether a given document from a WG is suitable as an Internet
> standard, which is most certainly a value judgement.
>
> Standards bodies do not exist merely to generate documents; they exist
> to develop and approve documents as standards and that requires making
> choices about what to approve and what to reject. This has always been
> true, and it is true not only in the IT industry, but in standards
> bodies for construction, safety, electrical engineering, etc.  Why can't
> you understand this fundamental principle?
>
>> WG Chairs are there (they exist) as facilitators to make sure that
>> fair and
>> open and the rest of the language about WG's and the IETF's standards
>> process are implemented. Which is to say you as a WG Chair were the
>> implementer of policy not its creator.
>
>
> Wrong again. WG chairs are usually subject matter experts and as such
> participate in the development of the standards in their WGs.  In a
> number of instances they are even authors or co-authors of documents
> within the WGs they chair.
>
>> Oh - as to the comment you made to me about veiled threats - I don't make
>> them.
>>
>> Todd Glassey
>
>
> Well, you have managed to fool a lot of folks in that regard, because
> that it precisely how all of your "if you keep behaving this way someone
> may sue you" comments are interpreted by many.  And, you have received
> feedback from others. not just me, saying precisely that. So, if your
> intent is not to be perceived that way, you should learn to rephrase
> yoor comments.
>
> Steve

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGTZqt097173 for <[e-mail]>; Wed, 13 Aug 2003 09:29:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DGTZUX097172 for ietf-pkix-bks; Wed, 13 Aug 2003 09:29:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGTWqt097150 for <[e-mail]>; Wed, 13 Aug 2003 09:29:33 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (92.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.92]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003081316291511100d9crje>; Wed, 13 Aug 2003 16:29:16 +0000
Message-ID: <00a801c361b8$09ad60a0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Date: Wed, 13 Aug 2003 08:44:24 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01C36177.1910CDC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_009D_01C36177.1910CDC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  ----- Original Message -----=20
  From: Alice Sturgeon=20
  To: Denis Pinkas=20
  Cc: [e-mail]=20
  Sent: Wednesday, August 13, 2003 3:10 AM
  Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt


  Hello Denis,
  Please see my comments inserted below, as [AS2], to distinguish from =
the first set of replies to your original comments.

  Alice

  Alice Sturgeon
  Chair, Canadian Advisory Committee - Information Technology Security
  ISO/IEC JTC 1/SC 27
  and
  System Policy Architect & Manager of Standards
  SPYRUS



  -----Original Message-----
  From: [e-mail]
  [mailto:[e-mail]]On Behalf Of Denis Pinkas
  Sent: Tuesday, July 29, 2003 6:38 AM
  To: [e-mail]
  Cc: [e-mail]
  Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt



  Alice,

  Please see my responses below.

  Comments on warranty-extn-03.txt (June 2003)

  1- On page 2. The text mentions: "A relying party that has a warranty =
from a
  CA".

  Does this mean that a relying party must have a contract with the CA =
to get
  advantage of the warranty ?
  [Alice] No.

  Does this mean that a relying party will get a warranty without a =
contract
  signed with the CA ?
  [Alice] Yes.

  Does this extension allow to make the difference between the case of a
  signed contract and the case of an unsigned contract where the =
guarantees
  could be different?

  [Alice] No. If there are any differences in the T&C pertaining to a
  contractual arrangement, these differences will be outside of, beyond =
the
  scope, and not pertinent to, the warranty offered in the certificate.  =
It
  applies equally to all relying parties, whether or not a contract has =
been
  signed.

  [Denis] Then say something like: "Whether or not relying parties have =
signed
  agreements with CAs, the CA will provide Terms and Conditions for this
  warranty which relates to its liability."

  [AS2] Alternatively, to make the same point, it could remain implicit. =



This is why I suggested that a T&C or Policy Negotiation protocol was =
needed. In fact any "deal" struck between the parties that references =
the indemntiy deal provided by one of the parties or a third-party =
indemnity provider, does in fact need to be uniquely referenceable and I =
agree with Alice that a hash of the approved T&C's that make up the the =
offering and accfptance of the reliance contract are enforcable. That =
means in any manner that a contractual relationship are to be codified =
by some set of digital transactions all the terms and conditions must be =
stated and agreed to ahead of time.=20

Further, if the CA is to change any of these terms it MUST also notify =
all parties which may mean there is a notification responsibility from =
the reseller or party offering the indemnity services to the client or =
recipient of the services.



  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 ::=3D CHOICE  {
          none                 NULL,            -- No warranty provided
          wData                WarrantyData  }  -- Explicit warranty

      WarrantyData ::=3D 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.



The real question is how to in a data-efficient manner to be able to =
represent these contract provisions or agreements, and as I suggested =
some time ago an OID Discovery Process is in order since OID's are the =
obvious method of making this work.



  [Alice] The computer does not need to know what is in the T&C. =20



But more importantly the COmputer CANNOT know anything. It has no =
concious mentality, no realization of "I think therefore I am" and so =
under US and all other law that I can see, the computer is only a =
presentation service for a commercial process (in this instance) and the =
computer is not the Agent so it, itself, needs none of this.

Which brings us to one of the flaws in the Warranty Process model - is =
it for computers or people? - If its a mechanism for CA's to advertise =
and accept commerce bnased on what indemnity offerings they have, then =
there is no need for any Human Readable parts. If its a digital T&C =
negotiation process, and the Human is particularly specific to this =
protocol's operations then the URL makes sense. If its both then, we =
will likely have confusion unless there is some receipt process added =
for displaying the T&C's in any given digital transaction.



  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.=20

  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?=20


YES!


  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.=20

  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=20

you mean the Indemnetor right?

  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."



This is at best a slippery slope.



  [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. =20

  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.=20

  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. =20


  Denis




------=_NextPart_000_009D_01C36177.1910CDC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">Alice=20
  Sturgeon</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Denis Pinkas</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, August 13, =
2003 3:10=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: I-D=20
  ACTION:draft-ietf-pkix-warranty-extn-03.txt</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>Hello Denis,<BR>Please see my comments inserted =
below, as=20
  [AS2], to distinguish from the first set of replies to your original=20
  comments.<BR><BR>Alice<BR><BR><STRONG>Alice Sturgeon<BR>Chair, =
Canadian=20
  Advisory Committee - Information Technology Security<BR>ISO/IEC JTC =
1/SC=20
  27<BR>and<BR>System Policy Architect &amp; Manager of=20
  Standards<BR>SPYRUS<BR></STRONG><BR><BR><BR>-----Original=20
  Message-----<BR>From: <A=20
  =
href=3D"mailto:[e-mail]">[e-mail]=
</A><BR>[<A=20
  =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]On=20
  Behalf Of Denis Pinkas<BR>Sent: Tuesday, July 29, 2003 6:38 AM<BR>To:=20
  [e-mail]<BR>Cc: [e-mail]<BR>Subject: Re: I-D=20
  =
ACTION:draft-ietf-pkix-warranty-extn-03.txt<BR><BR><BR><BR>Alice,<BR><BR>=
Please=20
  see my responses below.<BR><BR>Comments on warranty-extn-03.txt (June=20
  2003)<BR><BR>1- On page 2. The text mentions: "A relying party that =
has a=20
  warranty from a<BR>CA".<BR><BR>Does this mean that a relying party =
must have a=20
  contract with the CA to get<BR>advantage of the warranty ?<BR>[Alice]=20
  No.<BR><BR>Does this mean that a relying party will get a warranty =
without a=20
  contract<BR>signed with the CA ?<BR>[Alice] Yes.<BR><BR>Does this =
extension=20
  allow to make the difference between the case of a<BR>signed contract =
and the=20
  case of an unsigned contract where the guarantees<BR>could be=20
  different?<BR><BR>[Alice] No. If there are any differences in the =
T&amp;C=20
  pertaining to a<BR>contractual arrangement, these differences will be =
outside=20
  of, beyond the<BR>scope, and not pertinent to, the warranty offered in =
the=20
  certificate.&nbsp; It<BR>applies equally to all relying parties, =
whether or=20
  not a contract has been<BR>signed.<BR><BR>[Denis] Then say something =
like:=20
  "Whether or not relying parties have signed<BR>agreements with CAs, =
the CA=20
  will provide Terms and Conditions for this<BR>warranty which relates =
to its=20
  liability."</FONT></P>
  <P><FONT size=3D2>[AS2] Alternatively, to make the same point, it =
could remain=20
  implicit. </FONT></P><FONT size=3D2></FONT></BLOCKQUOTE>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT size=3D2><FONT face=3DArial>This is why I suggested =
that a=20
T&amp;C or Policy Negotiation protocol was needed. In fact any "deal" =
struck=20
between the parties that references the indemntiy deal provided by one =
of the=20
parties or a third-party indemnity provider, does in fact need to be =
uniquely=20
referenceable and I agree with Alice that a hash of the approved =
T&amp;C's that=20
make up the the offering and accfptance of the reliance contract are =
enforcable.=20
That means in any manner that a contractual relationship are to be =
codified by=20
some set of digital transactions all the terms and conditions must be =
stated and=20
agreed to ahead of time. </FONT></FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Further, if the CA is to =
change any of=20
these terms it MUST also notify all parties which may mean there is a=20
notification responsibility from the reseller or party offering the =
indemnity=20
services to the client or recipient of the services.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT size=3D2><FONT face=3DArial></FONT>&nbsp;</DIV>
  <P><BR><BR>2 - The difference between the base warranty and the =
extended=20
  warranty is<BR>not crystal clear.<BR><BR>How can a relying party know =
whether=20
  it can have the benefits of the base<BR>warranty or of the extended =
warranty=20
  ?<BR><BR>If the extended warranty is present, then the relying party =
has the=20
  benefit<BR>of the extended warranty.&nbsp; In short, if it is present, =
then=20
  the relying<BR>party knows that the relying party has the benefit of =
the=20
  extended warranty<BR>by its presence alone.&nbsp; The syntax shows =
that the=20
  extended warranty MAY be<BR>present:<BR>&nbsp; Warranty ::=3D =
CHOICE&nbsp;=20
  {<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
none&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
NULL,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- No=20
  warranty provided<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
wData&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
  WarrantyData&nbsp; }&nbsp; -- Explicit =
warranty<BR><BR>&nbsp;&nbsp;&nbsp;=20
  WarrantyData ::=3D SEQUENCE&nbsp;=20
  {<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  WarrantyInfo,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
extended&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
  WarrantyInfo OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
tcURL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
  TermsAndConditionsURL OPTIONAL&nbsp; }<BR><BR>If the tcURL is present, =
a human=20
  being might understand the terms and<BR>conditions (if he can =
understand the=20
  local language used), but a computer<BR>program will not be able to do =
so.=20
  This means that computers cannot<BR>understand the difference.</P>
  <P><FONT face=3DArial></FONT>&nbsp;</P></BLOCKQUOTE>
<P dir=3Dltr><FONT face=3DArial>The real question is how to in a =
data-efficient=20
manner to be able to represent these contract provisions or agreements, =
and as I=20
suggested some time ago an OID Discovery Process is in order since OID's =
are the=20
obvious method of making this work.</FONT></P><FONT =
face=3DArial></FONT></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"><FONT=20
  size=3D2>
  <P><BR><BR>[Alice] The computer does not need to know what is in the=20
  T&amp;C.&nbsp; </P>
  <P><FONT face=3DArial></FONT>&nbsp;</P></BLOCKQUOTE>
<P dir=3Dltr><FONT face=3DArial>But more importantly the COmputer CANNOT =
know=20
anything. It has no concious mentality, no realization of "I think =
therefore I=20
am" and so under US and all other law that I can see, the computer is =
only a=20
presentation service for a commercial process (in this instance) and the =

computer is not the Agent so it, itself, needs none of this.</FONT></P>
<P dir=3Dltr><FONT face=3DArial>Which brings us to one of the flaws in =
the Warranty=20
Process model - is it for computers or people? - If its a mechanism for =
CA's to=20
advertise and accept commerce bnased on what indemnity offerings they =
have, then=20
there is no need for any Human Readable parts. If its a digital T&amp;C=20
negotiation process, and the Human is particularly specific to this =
protocol's=20
operations then the URL makes sense. If its both then, we will likely =
have=20
confusion unless there is some receipt process added for displaying the=20
T&amp;C's in any given digital transaction.</FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT face=3DArial></FONT>&nbsp;</P>
  <P>If the tcURL<BR>is present, it is optionally for the benefit of the =
human=20
  reader. Perhaps<BR>you could suggest some text to clarify this in the =
I-D if=20
  you still think it<BR>is needed.<BR><BR>[Denis] Then say something =
like:=20
  "Warranty extensions are only aimed for<BR>human interpretation and =
contain=20
  data that is inappropriate for computer<BR>based verification schemes, =
the=20
  warranty extension MUST NOT be an active<BR>component in automated=20
  certification path validation."</FONT></P>
  <P><FONT size=3D2>[AS2] But this is not necessarily true. It may be =
that the RP=20
  (i.e., the human) has to go to a T&amp;C document if the extended =
warranty is=20
  present, if the RP wants to know what exactly is in the T&amp;C, but =
there=20
  should be the option of not going to the T&amp;C.&nbsp; If the =
extended=20
  warranty is not present (as noted in the syntax, it is optional), then =
there=20
  is no reason that the extension could not be processed by the =
computer.=20
  Therefore, the warranty extension is NOT "only aimed for human=20
  interpretation...".&nbsp; This may be irrelevant to the point of =
automated=20
  certificate path validation, because the extension is non-critical. =
<BR><BR>3=20
  - There is no security on the information placed at the tcURL=20
  parameter<BR>since no hash of the terms and conditions is being used. =
These=20
  conditions<BR>could change overtime and relying parties would not be =
able to=20
  demonstrate<BR>that they have changed.<BR><BR>[Alice]<BR>It seems to =
me that=20
  the time stamp on the certificate would suffice to place<BR>the =
warranty in a=20
  point of time at which the specified terms and conditions<BR>applied; =
there is=20
  no need for the extension to demonstrate that as this is<BR>covered by =
the=20
  certificate itself.&nbsp; This is no different from the<BR>paper-based =
world=20
  in that if an insurance policy changes its terms, it<BR>cannot do so=20
  retroactively to the detriment of clients who have paid for =
a<BR>specific=20
  coverage, unless it notified the clients and compensates=20
  them<BR>accordingly.<BR><BR>[Denis] The problem is that the CA could =
change=20
  the policy and the relying<BR>party will be unable to demonstrate that =
the=20
  policy has changed. A<BR>time-stamp token over the certificate would =
not help.=20
  A time-stamp token<BR>over the T&amp;C would help, but the relying =
party does=20
  not necessarily have<BR>access to one TSU. The hash approach is much=20
  simpler.</FONT></P>
  <P><FONT size=3D2>[AS2] A hash function on the T&amp;C? =
</FONT></P><FONT=20
  size=3D2></FONT></BLOCKQUOTE>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT size=3D2><FONT =
face=3DArial>YES!</FONT></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT size=3D2><BR><BR>4 - Is the "Relying party Agreement" a =
document to=20
  signed by the parties or<BR>not ? This should be =
said.<BR><BR>[Alice]<BR>Use=20
  of the term "Relying Party Agreement" is no different from its=20
  normal<BR>usage, just as "Certificate Policy" is used in the same =
context=20
  without any<BR>change to the meaning from normal usage, as per RFC =
2527 and=20
  its successor.<BR>In other words, defining the terms, either Relying =
Party=20
  Agreement or<BR>Certificate Policy is not necessary to the =
understanding of=20
  this extension.<BR><BR>[Denis] The term "Relying Party Agreement" is=20
  confusing. Use a wording like<BR>"Terms and Conditions for Relying =
parties"=20
  which does not imply that there<BR>is an agreement signed but that=20
  unilaterally the CA provides terms and<BR>conditions. Relying parties =
may like=20
  them or not. If they disagree with<BR>them, then this is still "Terms =
and=20
  Conditions for Relying parties".</FONT></DIV>
  <P><FONT size=3D2>[AS2] Maybe so, but the RP has the option of not =
using or=20
  relying on the certificate. As I said before, this is normal =
terminology, and=20
  should not be confusing; it is not being used with a different =
meaning.=20
  <BR><BR>5 - The WarrantyValidityPeriod is insufficient. Usually there =
is a=20
  period to<BR>claim for a compensation which must be made X months or Y =
days=20
  after the<BR>date of the event which created the damage. It is thus =
not=20
  possible to ask<BR>for a warranty during e.g. the whole validity =
period of the=20
  certificate.<BR>Another time period parameter is=20
  missing.<BR><BR>[Alice]<BR>This is exactly what the validity period is =

  stating: that the warranty is<BR>valid for a specified time, which is =
either=20
  the validity period of the<BR>certificate, or another, specified time =
using=20
  the parameters as defined in<BR>the I-D.&nbsp; It is presented and =
offered=20
  this way, so there is no need for<BR>another validity parameter.&nbsp; =
If an=20
  offeror </FONT></P></BLOCKQUOTE>
<P dir=3Dltr><FONT size=3D2>you mean the Indemnetor right?</FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>wanted to specify a time within<BR>which claims =
could be made,=20
  then a shorter time period than the validity of<BR>the certificate can =
be=20
  used.&nbsp; This is unlike the paper-based world in the<BR>sense that=20
  insurance policies are normally of long duration, whereas =
this<BR>extension is=20
  associated with a certificate that normally has a validity =
of<BR>two-three=20
  years.<BR><BR>[Denis] The semantics of the warranty validity period is =
not=20
  defined ! There<BR>is a need to define more precisely what "the =
warranty=20
  validity period" is.<BR>Here is a proposal along my original text. If =
it does=20
  not fit, please<BR>propose an alternative:<BR><BR>" The warranty =
validity=20
  period is a time period to claim for a compensation<BR>which must be =
made X=20
  months or Y days after the date of the event which<BR>created the =
damage. It=20
  is unrelated to the certificate validity period."</FONT></P>
  <P><FONT size=3D2></FONT>&nbsp;</P></BLOCKQUOTE>
<P dir=3Dltr><FONT size=3D2>This is at best a slippery slope.</FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT size=3D2></FONT>&nbsp;</P>
  <P><FONT size=3D2>[AS2] What if the warranty validity period is indeed =
the same=20
  as the certificate validity period? This was the scenario assumed to =
be most=20
  likely, as it is stated in s.2.2, and therefore the option was created =
to=20
  allow for a reduction in size of the extension by having NULL in =
warranty=20
  validity period in the case where it was the same as the certificate =
validity=20
  period.&nbsp; When it is not the same as the certificate validity =
period, then=20
  the parameters available for warranty validity period can be =
used.&nbsp;=20
  <BR><BR>6 - The wType offers only two types of warranty: aggregated =
and=20
  per<BR>transaction.<BR><BR>"Aggregated" means that that once the value =
of the=20
  fulfilled claims reaches<BR>the maximum warranty amount, then no =
further claim=20
  will be fulfilled.<BR><BR>"Per transaction" means that each claim is =
handled=20
  independently but no<BR>individual claim can exceed the maximum =
warranty=20
  amount.<BR><BR>Each type has its own problems:<BR><BR>"Aggregated" is =
like a=20
  race where late claimants will get no compensation at<BR>all because =
they were=20
  not "fast enough". It is questionable whether such a<BR>race condition =
will be=20
  acceptable.<BR>It should be understood that aggregation applies to one =

  warranty and one<BR>claimant.&nbsp; This is analogous to the =
paper-based=20
  world.&nbsp; When you are covered<BR>by warranty for X product or =
service,=20
  e.g., health insurance, there is often<BR>an upper limit (viz. the =
"value") up=20
  to which claims will be met for each<BR>claimant; i.e., one insured=20
  person.<BR>"Per transaction" means that the CA cannot compute the =
maximum=20
  amount of<BR>money that it may have to give away. Which insurance =
company will=20
  ever<BR>insure a risk for which an upper limit cannot be computed=20
  ?<BR><BR>[Alice]<BR>The T&amp;C, as noted in section 1, as covered by=20
  insurance, will specify the<BR>maximum. The type of warranty selected =
depends=20
  on the nature of the<BR>transactions, the parties to the transactions =
(e.g.,=20
  individuals, large<BR>institutions, etc.).<BR><BR>[Denis] What I am =
asking for=20
  is to allow a combination of both types, which<BR>is currently not =
possible.=20
  See below again.<BR><BR>None of these schemes is acceptable. Some =
combination=20
  should be allowed:<BR><BR>&nbsp;&nbsp; - a maximum amount per =
transaction,=20
  and<BR>&nbsp;&nbsp; - a maximum amount per certificate with a maximum =
time=20
  period<BR>&nbsp;&nbsp;&nbsp;&nbsp; to claim for a compensation after =
the date=20
  of the event<BR>&nbsp;&nbsp;&nbsp;&nbsp; (no race problem =
implied).</FONT></P>
  <P><FONT size=3D2>[AS2] You have a good point. We may need some =
clarification in=20
  s.2.2 to explain&nbsp;<SPAN class=3D756592221-12082003>exactly what=20
  the</SPAN>&nbsp;currency amount means.&nbsp; This is clearly stated =
(and=20
  obvious) with respect to aggregate, but not so with =
per-transaction.&nbsp; It=20
  should be indicated that there will be a maximum total of =
per-transaction=20
  claims, which would be standard practice, and necessary for the =
ongoing health=20
  of the CA.&nbsp;&nbsp;The total warranty offered for per-transaction=20
  claims&nbsp;<SPAN class=3D756592221-12082003>could be expressed =
as</SPAN><SPAN=20
  class=3D756592221-12082003> a new parameter indicating&nbsp;number of=20
  per-transaction claims&nbsp;before the maximum would br reached, which =
would=20
  be simple to calculate since the per-transaction maximum is stated;=20
  e.g.,&nbsp;a sub-line after the per-transaction type code, number of=20
  transactions as a maximum. </SPAN><BR><BR>7 - The content of the =
security=20
  consideration should be augmented to<BR>indicate the difference =
between what a=20
  computer program can do and a human<BR>being can do with this=20
  extension.<BR><BR>[Alice]<BR>I would have thought this to be =
blindingly=20
  obvious.&nbsp; We would, however, be<BR>quite willing to consider some =

  proposed words to address this, if you do<BR>think it is=20
  necessary.<BR><BR>[Denis] If my text proposal related to comment 2 is=20
  inserted, then this is<BR>no more needed.</FONT></P>
  <P><FONT size=3D2>[AS2] Still willing to consider a proposal, but as =
you can see=20
  from my response to your comments on point 2, I don't think this is =
quite=20
  right. <BR><BR>8 - The document is not mature enough and its added =
value is=20
  still<BR>questionable.<BR><BR>[Alice]<BR>We believe that it is =
mature.&nbsp;=20
  Its value may be questionable to those who do<BR>not want to use it, =
but given=20
  that it is (a) proposed as Informational and<BR>(b) always =
non-critical,=20
  surely its availability for use is innocuous for<BR>those that do not =
want to=20
  use it.&nbsp; For those who do want to use it, and we<BR>have heard =
from quite=20
  a number who do, it will be useful and valuable.&nbsp; As<BR>in =
section 1:=20
  "When a certificate contains a warranty certificate extension,<BR>the=20
  extension MUST be non-critical, ..."<BR><BR>[Denis]<BR>As you can see, =
we have=20
  progressed, but several issues still need to =
be<BR>addressed.</FONT></P>
  <P><FONT size=3D2>[AS2] Yes<SPAN class=3D756592221-12082003>, we have =
made=20
  progress.=20
</SPAN>&nbsp;<BR><BR><BR>Denis<BR><BR><BR></FONT></P></BLOCKQUOTE></BODY>=
</HTML>

------=_NextPart_000_009D_01C36177.1910CDC0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGPiqt096709 for <[e-mail]>; Wed, 13 Aug 2003 09:25:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DGPiTe096708 for ietf-pkix-bks; Wed, 13 Aug 2003 09:25:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGPgqt096700 for <[e-mail]>; Wed, 13 Aug 2003 09:25:42 -0700 (PDT)
Received: from above.proper.com (above.proper.com [208.184.76.39]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 479F8206607 for <[e-mail]>; Wed, 13 Aug 2003 12:24:10 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DFMVqt090446 for <[e-mail]>; Wed, 13 Aug 2003 08:22:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DFMVce090445 for ietf-pkix-bks; Wed, 13 Aug 2003 08:22:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DFMTqt090426 for <[e-mail]>; Wed, 13 Aug 2003 08:22:29 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (92.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.92]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003081315222211300cv2b9e>; Wed, 13 Aug 2003 15:22:23 +0000
Message-ID: <007501c361ae$b1f827e0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gietz" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <p05210604bb4eed81d497@[128.89.89.75]> <00f201c357c7$dfc95d10$020aff0a@tsg1> <p05210600bb501fcc5896@[128.89.89.75]> <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Wed, 13 Aug 2003 08:05:43 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

it is peter and your comments are dead on.

Todd
----- Original Message ----- 
From: "Peter Gietz" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "todd glassey" <[e-mail]>; "Peter Gutmann"
<[e-mail]>; <[e-mail]>
Sent: Wednesday, August 13, 2003 3:21 AM
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)


I am not really sure on what layer this thread is being discussed, but
my feeling is that it is rather on business and political layers than on
a technical one.

Multi-valued RDNs are not very complicated to support, basically it is
one more loop when analysing a DN added to the loop for the single
RDN-components of the DN. having found a RDN, you just loop once more to
find the single parts of a possibly multi-valued RDN. This can be
implemented within one day in any implementation. Most LDAP libraries
have a function called explode_RDN or similiar that helps you with this
additional loop.

There must be other reasons for not wanting to implement that, and I
suspect these reasons have more to do with interests in being not 100%
compliant to a standard.

BTW: The LDAP standard is very clear about the issue. RFC 2253 says:

> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
 >
>        RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
>         AttributeTypeAndValue
>
>        AttributeTypeAndValue ::= SEQUENCE {
>         type  AttributeType,
>         value AttributeValue }
[...]

> Where there is a multi-valued RDN, the outputs from adjoining
>    AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
>    character.

RFC 3280 uses exactly the same definition:

> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
>
>    RelativeDistinguishedName ::=
>      SET OF AttributeTypeAndValue
>
>    AttributeTypeAndValue ::= SEQUENCE {
>      type     AttributeType,
>      value    AttributeValue }


Very clear, very easy to implement, so what is all the fuzz about?

IETF standardization as other standardization activities is about
interoperability. People believing in such, should at least try to
implement the standards. There might be features that are too costly to
implement and I would understand discussions like this thread. In this
case the only point worth while mentioning is that Microsoft is not
implementing multi-valued RDNs and may be to ask representatives of that
company why they don't. In our X.509 certificate schema draft we do
acknowledge the fact, by specifying an alternative Name Form
(X.509issuerSerial), which BTW was not my idea. But reality check
shouldn't go further by saying "if company X (and may be one or two
others) don't support this, nobody should do it". This is not the IETF
spirit. And I am very fine with WG chairs that refuse to go along these
lines.

Cheers,

Peter

Stephen Kent wrote:

>
> At 17:56 -0700 7/31/03, todd glassey wrote:
>
>> Stephen this is the fundamental failing of the IESG to not 'slap you
>> silly'
>> for this... But you nor any other WG Chair were empowered to make your
>> WG a
>> fiefdom, so it is not for you to say what is and is not a standard nor
>> is it
>> appropriate for you to make any value judgments as a WG chair as to
>> what the
>> IETF is all about. That is for its members to decide and as a member
>> you get
>> one and only one vote... and as a WG Chair you get NO votes.
>
>
> As usual, you misunderstand.  The IETF is defined by its membership, and
> it empowers WG chairs, the IESG and the IAB to make value judgements. If
> the value judgements are seen to be inappropriate, there are appeal
> processes available to the parties who think they have been wronged.
> This is true of other standards bodies as well. Your notion of how a
> standards body should operate is NOT accepted or practiced by any of
> standards bodies with which I am familiar, e.g., ANSI, ITU, ETSI, IEEE,
> ...  Because we don't formally vote on matters, WG chairs also are
> empowered to decide when WG consensus is achieved.  IESG members must
> agree on whether a given document from a WG is suitable as an Internet
> standard, which is most certainly a value judgement.
>
> Standards bodies do not exist merely to generate documents; they exist
> to develop and approve documents as standards and that requires making
> choices about what to approve and what to reject. This has always been
> true, and it is true not only in the IT industry, but in standards
> bodies for construction, safety, electrical engineering, etc.  Why can't
> you understand this fundamental principle?
>
>> WG Chairs are there (they exist) as facilitators to make sure that
>> fair and
>> open and the rest of the language about WG's and the IETF's standards
>> process are implemented. Which is to say you as a WG Chair were the
>> implementer of policy not its creator.
>
>
> Wrong again. WG chairs are usually subject matter experts and as such
> participate in the development of the standards in their WGs.  In a
> number of instances they are even authors or co-authors of documents
> within the WGs they chair.
>
>> Oh - as to the comment you made to me about veiled threats - I don't make
>> them.
>>
>> Todd Glassey
>
>
> Well, you have managed to fool a lot of folks in that regard, because
> that it precisely how all of your "if you keep behaving this way someone
> may sue you" comments are interpreted by many.  And, you have received
> feedback from others. not just me, saying precisely that. So, if your
> intent is not to be perceived that way, you should learn to rephrase
> yoor comments.
>
> Steve

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DFMVqt090446 for <[e-mail]>; Wed, 13 Aug 2003 08:22:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DFMVce090445 for ietf-pkix-bks; Wed, 13 Aug 2003 08:22:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DFMTqt090426 for <[e-mail]>; Wed, 13 Aug 2003 08:22:29 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (92.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.92]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003081315222211300cv2b9e>; Wed, 13 Aug 2003 15:22:23 +0000
Message-ID: <007501c361ae$b1f827e0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gietz" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <p05210604bb4eed81d497@[128.89.89.75]> <00f201c357c7$dfc95d10$020aff0a@tsg1> <p05210600bb501fcc5896@[128.89.89.75]> <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Wed, 13 Aug 2003 08:05:43 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

it is peter and your comments are dead on.

Todd
----- Original Message ----- 
From: "Peter Gietz" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "todd glassey" <[e-mail]>; "Peter Gutmann"
<[e-mail]>; <[e-mail]>
Sent: Wednesday, August 13, 2003 3:21 AM
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)


I am not really sure on what layer this thread is being discussed, but
my feeling is that it is rather on business and political layers than on
a technical one.

Multi-valued RDNs are not very complicated to support, basically it is
one more loop when analysing a DN added to the loop for the single
RDN-components of the DN. having found a RDN, you just loop once more to
find the single parts of a possibly multi-valued RDN. This can be
implemented within one day in any implementation. Most LDAP libraries
have a function called explode_RDN or similiar that helps you with this
additional loop.

There must be other reasons for not wanting to implement that, and I
suspect these reasons have more to do with interests in being not 100%
compliant to a standard.

BTW: The LDAP standard is very clear about the issue. RFC 2253 says:

> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
 >
>        RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
>         AttributeTypeAndValue
>
>        AttributeTypeAndValue ::= SEQUENCE {
>         type  AttributeType,
>         value AttributeValue }
[...]

> Where there is a multi-valued RDN, the outputs from adjoining
>    AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
>    character.

RFC 3280 uses exactly the same definition:

> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
>
>    RelativeDistinguishedName ::=
>      SET OF AttributeTypeAndValue
>
>    AttributeTypeAndValue ::= SEQUENCE {
>      type     AttributeType,
>      value    AttributeValue }


Very clear, very easy to implement, so what is all the fuzz about?

IETF standardization as other standardization activities is about
interoperability. People believing in such, should at least try to
implement the standards. There might be features that are too costly to
implement and I would understand discussions like this thread. In this
case the only point worth while mentioning is that Microsoft is not
implementing multi-valued RDNs and may be to ask representatives of that
company why they don't. In our X.509 certificate schema draft we do
acknowledge the fact, by specifying an alternative Name Form
(X.509issuerSerial), which BTW was not my idea. But reality check
shouldn't go further by saying "if company X (and may be one or two
others) don't support this, nobody should do it". This is not the IETF
spirit. And I am very fine with WG chairs that refuse to go along these
lines.

Cheers,

Peter

Stephen Kent wrote:

>
> At 17:56 -0700 7/31/03, todd glassey wrote:
>
>> Stephen this is the fundamental failing of the IESG to not 'slap you
>> silly'
>> for this... But you nor any other WG Chair were empowered to make your
>> WG a
>> fiefdom, so it is not for you to say what is and is not a standard nor
>> is it
>> appropriate for you to make any value judgments as a WG chair as to
>> what the
>> IETF is all about. That is for its members to decide and as a member
>> you get
>> one and only one vote... and as a WG Chair you get NO votes.
>
>
> As usual, you misunderstand.  The IETF is defined by its membership, and
> it empowers WG chairs, the IESG and the IAB to make value judgements. If
> the value judgements are seen to be inappropriate, there are appeal
> processes available to the parties who think they have been wronged.
> This is true of other standards bodies as well. Your notion of how a
> standards body should operate is NOT accepted or practiced by any of
> standards bodies with which I am familiar, e.g., ANSI, ITU, ETSI, IEEE,
> ...  Because we don't formally vote on matters, WG chairs also are
> empowered to decide when WG consensus is achieved.  IESG members must
> agree on whether a given document from a WG is suitable as an Internet
> standard, which is most certainly a value judgement.
>
> Standards bodies do not exist merely to generate documents; they exist
> to develop and approve documents as standards and that requires making
> choices about what to approve and what to reject. This has always been
> true, and it is true not only in the IT industry, but in standards
> bodies for construction, safety, electrical engineering, etc.  Why can't
> you understand this fundamental principle?
>
>> WG Chairs are there (they exist) as facilitators to make sure that
>> fair and
>> open and the rest of the language about WG's and the IETF's standards
>> process are implemented. Which is to say you as a WG Chair were the
>> implementer of policy not its creator.
>
>
> Wrong again. WG chairs are usually subject matter experts and as such
> participate in the development of the standards in their WGs.  In a
> number of instances they are even authors or co-authors of documents
> within the WGs they chair.
>
>> Oh - as to the comment you made to me about veiled threats - I don't make
>> them.
>>
>> Todd Glassey
>
>
> Well, you have managed to fool a lot of folks in that regard, because
> that it precisely how all of your "if you keep behaving this way someone
> may sue you" comments are interpreted by many.  And, you have received
> feedback from others. not just me, saying precisely that. So, if your
> intent is not to be perceived that way, you should learn to rephrase
> yoor comments.
>
> Steve

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DBbAqt073835 for <[e-mail]>; Wed, 13 Aug 2003 04:37:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DBbA6H073834 for ietf-pkix-bks; Wed, 13 Aug 2003 04:37:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DBb8qt073828 for <[e-mail]>; Wed, 13 Aug 2003 04:37:09 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.200.130]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id h7DBZi4f015732 for <[e-mail]>; Wed, 13 Aug 2003 17:35:51 +0600 (PKST)
Message-ID: <003c01c3618f$82676e60$[e-mail]>
From: "Faisal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 13 Aug 2003 16:38:57 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_0035_01C361B9.64924F20"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01C361B9.64924F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

    In X509Certificate, there is extension which guides us about ocsp
server. I request to write a draft for scvp-aia-extension for future support
of SCVP in X509Certificate.

Kind Regards,
Faisal

----- Original Message -----
From: <[e-mail]>
To: <IETF-Announce:>
Cc: <[e-mail]>
Sent: Monday, August 04, 2003 7:14 PM
Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : AIA Access Method for XKMS Services
> Author(s) : A. Deacon
> Filename : draft-deacon-xkms-aia-00.txt
> Pages : 5
> Date : 2003-8-4
>
> Authority Information Access extension that is used to indicate how
> to access CA information and services for the issuer of the
> certificate in which this extension appears.  This document defines
> an access method identifier that indicates the location of XKMS
> [XKMS] services.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-deacon-xkms-aia-00.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-deacon-xkms-aia-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-deacon-xkms-aia-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5TCCAzEw
ggIZoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMRkwFwYDVQQDExBBc2NlcnRpYSBSb290IENBMB4XDTAzMDMwNDA4MTI1N1oXDTEyMDczMDEw
NDIyOVowYDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAy
IENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAnRehtg8oWu+jYIkNJVR1ueHs7k8fClUiqUsrjmhuaI6SGjw0eusF
FCCnDN2URjk+Un2OFHa3fn0lRFes/rIXvV0aB8pZGp8XJLO6u3pdfKJGnVeBtgBUr/YkXT/APo+z
pp6a52+VjOEA8tcsfkco+Ml4quvZRSQ6/5hvDlEnm08CAwEAAaOBnjCBmzAOBgNVHQ8BAf8EBAMC
AQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUc/Pyi9HYduL1F1K9IjZs+KkJi3QwNQYI
KwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhl3d3cuZ2xvYmFsdHJ1c3RmaW5kZXIuY29tMB8GA1Ud
IwQYMBaAFLFTcaAo/ecMU5odaxA87sgazV7OMA0GCSqGSIb3DQEBBQUAA4IBAQAWgwuPN1Kt4P+g
mBe25iHuepjjWcslDjZaC65ZxQuGjr/Aj7eKtBwpvw+01S4r9QIKQeT0DqlcFJlf3mDa6S25ZKxR
hUM74fxSYvfT1hAFd7NMZ2BYSj5bGHX5LWFQi1REDthiggjUt5QUGj+OVDfqBakynkiYMinw+NV0
gdRzMyhE3j3nWzeXrOXOmzea3o4bsLK2yCAJ6v+VjjTs+gBlCIE2aqSdctX2JOFJLQUyWlArBqZ9
CEdVW+iYS7PYRnOddXLiX3EC/7+MlbNMZSW234XzWQxrNqF8JzUXbYHm3jDMsprDdeC8RtiYAhQa
T/Ogeq21ndR7phpmrMQqYCSBMIIDajCCAlKgAwIBAgIBATANBgkqhkiG9w0BAQUFADA7MQswCQYD
VQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwHhcN
MDMwMzA0MDgwNjEyWhcNMTMwMzA0MDgwMTI3WjA7MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNj
ZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDR+NPebia/iGElNG3QI9TlQSWE+vwhh9N1p608htxwX3HG2PREDou8hP/r3pIkkJEs
flGxt3RVXK+Ut7IyKKB17rhlUSGmrqaRL2fAxyCsCbtak6uLqh7afDYesI1ozLn4sYMFeFWGCWKk
kNBzGfDvKebjXAz9yNxhFyLGbB+ZUkEsfjQA3GJ4Dza4FAbWUH/Q9jWpd8RU9Wx9Hi+QTfXOTaaW
Tn+QMRg9QWuP6pklSsGA65j9YWoBd+ONtSEUM0aX3p/iuecSqC/IjfSxa7hWCskQR+bzqg3xMJTa
R1JpCQds6Z1OqJX5R3UEh71FaxC2TTMgGhNDhwVuoxEgSPhlAgMBAAGjeTB3MA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSxU3GgKP3nDFOaHWsQPO7IGs1ezjA1Bggr
BgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20wDQYJKoZI
hvcNAQEFBQADggEBAKRrsf6/A8LzMqEFJcKl3pq41fPXH7gDLbayGYxvRJ15LRMwxy6A8A2SrY5r
V8u8PStKcMGKj/1R4q1zY/h2TH0eIHDNzIcXiAndZFNBIRPskQ1qIKIlTtO/TYC1f+qss9r7eKcw
Yk90WhdkdZ0k/r21Z7JQMtLGvgO+2Mc4LEb4f1Li/TdB3M0dBq0nRrDX5wiM3hoRbYkWn+0rNtHl
4fVqp5M0S9BeWud/jNIiPu2OSFCdiXDgYVYP56OfVYHuUQuTGfsRP8EI3uUE5RFqIPBj+Vx/Dwzt
/LnNR2CfKv6HPS5AstKZWr04k/RKserIBmJLuxohgfnUuLWJovLFPJkwggQ+MIIDp6ADAgECAgEF
MA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEmMCQGA1UE
CxMdQ2xhc3MgMiBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxFjAUBgNVBAMTDUFzY2VydGlhIENBIDIw
HhcNMDMwMzA1MDYyNDEwWhcNMDQwMzA1MDYwOTM0WjBPMQswCQYDVQQGEwJHQjERMA8GA1UEChMI
QXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRcwFQYDVQQDEw5GYWlzYWwgTWFxc29vZDCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnsqY9Z9dFOdNIgrbdeM6AjpVsMferv2JSGKmLsj+
b0Yahb4NF4O7wu0f6PxQV3OehEJDc3QWWt1WwGvCgxQAcjTSeSjtZtc5pNcM5c2jByglHy3OXu+m
QuycMr7xCevqhgbxRKOAkpLSz4y/HXkvE4UnEqeZ02hofC57Q6LcVUECAwEAAaOCAhcwggITMA4G
A1UdDwEB/wQEAwID+DAMBgNVHRMBAf8EAjAAMIIBAwYDVR0gBIH7MIH4MIH1BgorBgEEAfxJAQIB
MIHmMIHjBggrBgEFBQcCAjCB1hqB01RoaXMgY2VydGlmaWNhdGUgaXMgZm9yIHRoZSBzb2xlIHVz
ZSBvZiBBc2NlcnRpYSwgYW5kIGl0cyBjdXN0b21lcnMuIEFzY2VydGlhIGFjY2VwdHMgbm8gbGlh
YmlsaXR5IGZvciBhbnkgY2xhaW0gZXhjZXB0IGFzIGV4cHJlc3NseSBwcm92aWRlZCBpbiBpdHMg
Q2VydGlmaWNhdGUgUG9saWN5LCB3aGljaCBpcyBhdmFpbGFibGUgZnJvbSBpbmZvQGFzY2VydGlh
LmNvbS4wHQYDVR0OBBYEFOtaj3aL8msQJzzETwoXrMw4lV3MME0GA1UdHwRGMEQwQqBAoD6GPGh0
dHA6Ly93d3cuYXNjZXJ0aWEuY29tL09ubGluZUNBL2NybHMvQXNjZXJ0aWFDQTIvY2xhc3MyLmNy
bDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20w
JgYDVR0RBB8wHYEbZmFpc2FsLm1hcXNvb2RAYXNjZXJ0aWEuY29tMB8GA1UdIwQYMBaAFHPz8ovR
2Hbi9RdSvSI2bPipCYt0MA0GCSqGSIb3DQEBBQUAA4GBAHVhWHsCvmtTG4Q7u8HC8ZpdWdwVHqZm
CYbxwUN+C8QzuMzrweaxE7wUE8U7TkSOBVUrJqV9FC4gfDO35VmFTbqhpugurVahb0xop0baD6LW
YoB12Fvz1BFEG3U+liNlD434TcPjFdKQYJVgwAT3cT/K9Nagp1tZJedmR3t2LinMMYIBuTCCAbUC
AQEwZTBgMQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExJjAkBgNVBAsTHUNsYXNzIDIg
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1Bc2NlcnRpYSBDQSAyAgEFMAkGBSsOAwIa
BQCggaswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwODEzMTEz
ODU3WjAjBgkqhkiG9w0BCQQxFgQUrfwVLnMLZECktdAEo1Z4sM8X3KswTAYJKoZIhvcNAQkPMT8w
PTANBggqhkiG9w0DAgIBKDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwBwYF
Kw4DAh0wDQYJKoZIhvcNAQEBBQAEgYA/I7uQxEryKI0IUCuUVBke1agqIqxaULCQODeWH/LlPATr
1tOYoP1txl2lJ98o+VYa5MKU4AnPen59lzhYmDhbbkBLhHcWLWC2WHdyIjsemP9cw8a2ySdhkCW7
brTsRXgx+tkkIXkOzger1VTfhIt+3ZGuSXqKx7YNz/zlQNaGaAAAAAAAAA==

------=_NextPart_000_0035_01C361B9.64924F20--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DAMEqt068684 for <[e-mail]>; Wed, 13 Aug 2003 03:22:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DAMEfZ068683 for ietf-pkix-bks; Wed, 13 Aug 2003 03:22:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DAMBqt068678 for <[e-mail]>; Wed, 13 Aug 2003 03:22:12 -0700 (PDT) (envelope-from [e-mail])
Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.3/8.11.6/SuSE Linux 0.5) with ESMTP id h7DAM8611296; Wed, 13 Aug 2003 12:22:08 +0200
Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) (authenticated (0 bits)) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h7DALxI28012 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified OK); Wed, 13 Aug 2003 12:22:07 +0200
Message-ID: <[e-mail]>
Date: Wed, 13 Aug 2003 12:21:58 +0200
From: Peter Gietz <[e-mail]>
Organization: DAASI International GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: todd glassey <[e-mail]>, Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
References: <p05210604bb4eed81d497@[128.89.89.75]> <00f201c357c7$dfc95d10$020aff0a@tsg1> <p05210600bb501fcc5896@[128.89.89.75]>
In-Reply-To: <p05210600bb501fcc5896@[128.89.89.75]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.54
X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7DAMDqt068679
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am not really sure on what layer this thread is being discussed, but 
my feeling is that it is rather on business and political layers than on 
a technical one.

Multi-valued RDNs are not very complicated to support, basically it is 
one more loop when analysing a DN added to the loop for the single 
RDN-components of the DN. having found a RDN, you just loop once more to 
find the single parts of a possibly multi-valued RDN. This can be 
implemented within one day in any implementation. Most LDAP libraries 
have a function called explode_RDN or similiar that helps you with this 
additional loop.

There must be other reasons for not wanting to implement that, and I 
suspect these reasons have more to do with interests in being not 100% 
compliant to a standard.

BTW: The LDAP standard is very clear about the issue. RFC 2253 says:

> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
 >
>        RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
>         AttributeTypeAndValue
> 
>        AttributeTypeAndValue ::= SEQUENCE {
>         type  AttributeType,
>         value AttributeValue }
[...]

> Where there is a multi-valued RDN, the outputs from adjoining
>    AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
>    character.

RFC 3280 uses exactly the same definition:

> RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
> 
>    RelativeDistinguishedName ::=
>      SET OF AttributeTypeAndValue
> 
>    AttributeTypeAndValue ::= SEQUENCE {
>      type     AttributeType,
>      value    AttributeValue }


Very clear, very easy to implement, so what is all the fuzz about?

IETF standardization as other standardization activities is about 
interoperability. People believing in such, should at least try to 
implement the standards. There might be features that are too costly to 
implement and I would understand discussions like this thread. In this 
case the only point worth while mentioning is that Microsoft is not 
implementing multi-valued RDNs and may be to ask representatives of that 
company why they don't. In our X.509 certificate schema draft we do 
acknowledge the fact, by specifying an alternative Name Form 
(X.509issuerSerial), which BTW was not my idea. But reality check 
shouldn't go further by saying "if company X (and may be one or two 
others) don't support this, nobody should do it". This is not the IETF 
spirit. And I am very fine with WG chairs that refuse to go along these 
lines.

Cheers,

Peter

Stephen Kent wrote:

> 
> At 17:56 -0700 7/31/03, todd glassey wrote:
> 
>> Stephen this is the fundamental failing of the IESG to not 'slap you 
>> silly'
>> for this... But you nor any other WG Chair were empowered to make your 
>> WG a
>> fiefdom, so it is not for you to say what is and is not a standard nor 
>> is it
>> appropriate for you to make any value judgments as a WG chair as to 
>> what the
>> IETF is all about. That is for its members to decide and as a member 
>> you get
>> one and only one vote... and as a WG Chair you get NO votes.
> 
> 
> As usual, you misunderstand.  The IETF is defined by its membership, and 
> it empowers WG chairs, the IESG and the IAB to make value judgements. If 
> the value judgements are seen to be inappropriate, there are appeal 
> processes available to the parties who think they have been wronged.  
> This is true of other standards bodies as well. Your notion of how a 
> standards body should operate is NOT accepted or practiced by any of 
> standards bodies with which I am familiar, e.g., ANSI, ITU, ETSI, IEEE, 
> ...  Because we don't formally vote on matters, WG chairs also are 
> empowered to decide when WG consensus is achieved.  IESG members must 
> agree on whether a given document from a WG is suitable as an Internet 
> standard, which is most certainly a value judgement.
> 
> Standards bodies do not exist merely to generate documents; they exist 
> to develop and approve documents as standards and that requires making 
> choices about what to approve and what to reject. This has always been 
> true, and it is true not only in the IT industry, but in standards 
> bodies for construction, safety, electrical engineering, etc.  Why can't 
> you understand this fundamental principle?
> 
>> WG Chairs are there (they exist) as facilitators to make sure that 
>> fair and
>> open and the rest of the language about WG's and the IETF's standards
>> process are implemented. Which is to say you as a WG Chair were the
>> implementer of policy not its creator.
> 
> 
> Wrong again. WG chairs are usually subject matter experts and as such 
> participate in the development of the standards in their WGs.  In a 
> number of instances they are even authors or co-authors of documents 
> within the WGs they chair.
> 
>> Oh - as to the comment you made to me about veiled threats - I don't make
>> them.
>>
>> Todd Glassey
> 
> 
> Well, you have managed to fool a lot of folks in that regard, because 
> that it precisely how all of your "if you keep behaving this way someone 
> may sue you" comments are interpreted by many.  And, you have received 
> feedback from others. not just me, saying precisely that. So, if your 
> intent is not to be perceived that way, you should learn to rephrase 
> yoor comments.
> 
> Steve

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D9x6qt066426 for <[e-mail]>; Wed, 13 Aug 2003 02:59:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7D9x65O066425 for ietf-pkix-bks; Wed, 13 Aug 2003 02:59:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from tomts20-srv.bellnexxia.net (tomts20.bellnexxia.net [209.226.175.74]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7D9x5qt066410 for <[e-mail]>; Wed, 13 Aug 2003 02:59:06 -0700 (PDT) (envelope-from [e-mail])
Received: from hippolyta ([209.226.190.125]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with SMTP id <20030813095849.IKJY29021.tomts20-srv.bellnexxia.net@hippolyta>; Wed, 13 Aug 2003 05:58:49 -0400
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Date: Wed, 13 Aug 2003 06:10:06 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C36161.8B1E5A10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C36161.8B1E5A10
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hello Denis,
Please see my comments inserted below, as [AS2], to distinguish from the
first set of replies to your original comments.

Alice

Alice Sturgeon
Chair, Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC 1/SC 27
and
System Policy Architect & Manager of Standards
SPYRUS



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Denis Pinkas
Sent: Tuesday, July 29, 2003 6:38 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt



Alice,

Please see my responses below.

Comments on warranty-extn-03.txt (June 2003)

1- On page 2. The text mentions: "A relying party that has a warranty from a
CA".

Does this mean that a relying party must have a contract with the CA to get
advantage of the warranty ?
[Alice] No.

Does this mean that a relying party will get a warranty without a contract
signed with the CA ?
[Alice] Yes.

Does this extension allow to make the difference between the case of a
signed contract and the case of an unsigned contract where the guarantees
could be different?

[Alice] No. If there are any differences in the T&C pertaining to a
contractual arrangement, these differences will be outside of, beyond the
scope, and not pertinent to, the warranty offered in the certificate.  It
applies equally to all relying parties, whether or not a contract has been
signed.

[Denis] Then say something like: "Whether or not relying parties have signed
agreements with CAs, the CA will provide Terms and Conditions for this
warranty which relates to its liability."

[AS2] Alternatively, to make the same point, it could remain implicit.

2 - The difference between the base warranty and the extended warranty is
not crystal clear.

How can a relying party know whether it can have the benefits of the base
warranty or of the extended warranty ?

If the extended warranty is present, then the relying party has the benefit
of the extended warranty.  In short, if it is present, then the relying
party knows that the relying party has the benefit of the extended warranty
by its presence alone.  The syntax shows that the extended warranty MAY be
present:
  Warranty ::= CHOICE  {
        none                 NULL,            -- No warranty provided
        wData                WarrantyData  }  -- Explicit warranty

    WarrantyData ::= SEQUENCE  {
        base                 WarrantyInfo,
        extended             WarrantyInfo OPTIONAL,
        tcURL                TermsAndConditionsURL OPTIONAL  }

If the tcURL is present, a human being might understand the terms and
conditions (if he can understand the local language used), but a computer
program will not be able to do so. This means that computers cannot
understand the difference.

[Alice] The computer does not need to know what is in the T&C.  If the tcURL
is present, it is optionally for the benefit of the human reader. Perhaps
you could suggest some text to clarify this in the I-D if you still think it
is needed.

[Denis] Then say something like: "Warranty extensions are only aimed for
human interpretation and contain data that is inappropriate for computer
based verification schemes, the warranty extension MUST NOT be an active
component in automated certification path validation."

[AS2] But this is not necessarily true. It may be that the RP (i.e., the
human) has to go to a T&C document if the extended warranty is present, if
the RP wants to know what exactly is in the T&C, but there should be the
option of not going to the T&C.  If the extended warranty is not present (as
noted in the syntax, it is optional), then there is no reason that the
extension could not be processed by the computer. Therefore, the warranty
extension is NOT "only aimed for human interpretation...".  This may be
irrelevant to the point of automated certificate path validation, because
the extension is non-critical.

3 - There is no security on the information placed at the tcURL parameter
since no hash of the terms and conditions is being used. These conditions
could change overtime and relying parties would not be able to demonstrate
that they have changed.

[Alice]
It seems to me that the time stamp on the certificate would suffice to place
the warranty in a point of time at which the specified terms and conditions
applied; there is no need for the extension to demonstrate that as this is
covered by the certificate itself.  This is no different from the
paper-based world in that if an insurance policy changes its terms, it
cannot do so retroactively to the detriment of clients who have paid for a
specific coverage, unless it notified the clients and compensates them
accordingly.

[Denis] The problem is that the CA could change the policy and the relying
party will be unable to demonstrate that the policy has changed. A
time-stamp token over the certificate would not help. A time-stamp token
over the T&C would help, but the relying party does not necessarily have
access to one TSU. The hash approach is much simpler.

[AS2] A hash function on the T&C?

4 - Is the "Relying party Agreement" a document to signed by the parties or
not ? This should be said.

[Alice]
Use of the term "Relying Party Agreement" is no different from its normal
usage, just as "Certificate Policy" is used in the same context without any
change to the meaning from normal usage, as per RFC 2527 and its successor.
In other words, defining the terms, either Relying Party Agreement or
Certificate Policy is not necessary to the understanding of this extension.

[Denis] The term "Relying Party Agreement" is confusing. Use a wording like
"Terms and Conditions for Relying parties" which does not imply that there
is an agreement signed but that unilaterally the CA provides terms and
conditions. Relying parties may like them or not. If they disagree with
them, then this is still "Terms and Conditions for Relying parties".

[AS2] Maybe so, but the RP has the option of not using or relying on the
certificate. As I said before, this is normal terminology, and should not be
confusing; it is not being used with a different meaning.

5 - The WarrantyValidityPeriod is insufficient. Usually there is a period to
claim for a compensation which must be made X months or Y days after the
date of the event which created the damage. It is thus not possible to ask
for a warranty during e.g. the whole validity period of the certificate.
Another time period parameter is missing.

[Alice]
This is exactly what the validity period is stating: that the warranty is
valid for a specified time, which is either the validity period of the
certificate, or another, specified time using the parameters as defined in
the I-D.  It is presented and offered this way, so there is no need for
another validity parameter.  If an offeror wanted to specify a time within
which claims could be made, then a shorter time period than the validity of
the certificate can be used.  This is unlike the paper-based world in the
sense that insurance policies are normally of long duration, whereas this
extension is associated with a certificate that normally has a validity of
two-three years.

[Denis] The semantics of the warranty validity period is not defined ! There
is a need to define more precisely what "the warranty validity period" is.
Here is a proposal along my original text. If it does not fit, please
propose an alternative:

" The warranty validity period is a time period to claim for a compensation
which must be made X months or Y days after the date of the event which
created the damage. It is unrelated to the certificate validity period."

[AS2] What if the warranty validity period is indeed the same as the
certificate validity period? This was the scenario assumed to be most
likely, as it is stated in s.2.2, and therefore the option was created to
allow for a reduction in size of the extension by having NULL in warranty
validity period in the case where it was the same as the certificate
validity period.  When it is not the same as the certificate validity
period, then the parameters available for warranty validity period can be
used.

6 - The wType offers only two types of warranty: aggregated and per
transaction.

"Aggregated" means that that once the value of the fulfilled claims reaches
the maximum warranty amount, then no further claim will be fulfilled.

"Per transaction" means that each claim is handled independently but no
individual claim can exceed the maximum warranty amount.

Each type has its own problems:

"Aggregated" is like a race where late claimants will get no compensation at
all because they were not "fast enough". It is questionable whether such a
race condition will be acceptable.
It should be understood that aggregation applies to one warranty and one
claimant.  This is analogous to the paper-based world.  When you are covered
by warranty for X product or service, e.g., health insurance, there is often
an upper limit (viz. the "value") up to which claims will be met for each
claimant; i.e., one insured person.
"Per transaction" means that the CA cannot compute the maximum amount of
money that it may have to give away. Which insurance company will ever
insure a risk for which an upper limit cannot be computed ?

[Alice]
The T&C, as noted in section 1, as covered by insurance, will specify the
maximum. The type of warranty selected depends on the nature of the
transactions, the parties to the transactions (e.g., individuals, large
institutions, etc.).

[Denis] What I am asking for is to allow a combination of both types, which
is currently not possible. See below again.

None of these schemes is acceptable. Some combination should be allowed:

   - a maximum amount per transaction, and
   - a maximum amount per certificate with a maximum time period
     to claim for a compensation after the date of the event
     (no race problem implied).

[AS2] You have a good point. We may need some clarification in s.2.2 to
explain exactly what the currency amount means.  This is clearly stated (and
obvious) with respect to aggregate, but not so with per-transaction.  It
should be indicated that there will be a maximum total of per-transaction
claims, which would be standard practice, and necessary for the ongoing
health of the CA.  The total warranty offered for per-transaction claims
could be expressed as a new parameter indicating number of per-transaction
claims before the maximum would br reached, which would be simple to
calculate since the per-transaction maximum is stated; e.g., a sub-line
after the per-transaction type code, number of transactions as a maximum.

7 - The content of the security consideration should be augmented to
indicate the difference between what a computer program can do and a human
being can do with this extension.

[Alice]
I would have thought this to be blindingly obvious.  We would, however, be
quite willing to consider some proposed words to address this, if you do
think it is necessary.

[Denis] If my text proposal related to comment 2 is inserted, then this is
no more needed.

[AS2] Still willing to consider a proposal, but as you can see from my
response to your comments on point 2, I don't think this is quite right.

8 - The document is not mature enough and its added value is still
questionable.

[Alice]
We believe that it is mature.  Its value may be questionable to those who do
not want to use it, but given that it is (a) proposed as Informational and
(b) always non-critical, surely its availability for use is innocuous for
those that do not want to use it.  For those who do want to use it, and we
have heard from quite a number who do, it will be useful and valuable.  As
in section 1: "When a certificate contains a warranty certificate extension,
the extension MUST be non-critical, ..."

[Denis]
As you can see, we have progressed, but several issues still need to be
addressed.

[AS2] Yes, we have made progress.


Denis




------=_NextPart_000_0000_01C36161.8B1E5A10
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<P><FONT size=3D2>Hello Denis,<BR>Please see my comments inserted below, =
as [AS2],=20
to distinguish from the first set of replies to your original=20
comments.<BR><BR>Alice<BR><BR><STRONG>Alice Sturgeon<BR>Chair, Canadian =
Advisory=20
Committee - Information Technology Security<BR>ISO/IEC JTC 1/SC=20
27<BR>and<BR>System Policy Architect &amp; Manager of=20
Standards<BR>SPYRUS<BR></STRONG><BR><BR><BR>-----Original =
Message-----<BR>From:=20
[e-mail]<BR>[<A=20
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]On=20
Behalf Of Denis Pinkas<BR>Sent: Tuesday, July 29, 2003 6:38 AM<BR>To:=20
[e-mail]<BR>Cc: [e-mail]<BR>Subject: Re: I-D=20
ACTION:draft-ietf-pkix-warranty-extn-03.txt<BR><BR><BR><BR>Alice,<BR><BR>=
Please=20
see my responses below.<BR><BR>Comments on warranty-extn-03.txt (June=20
2003)<BR><BR>1- On page 2. The text mentions: "A relying party that has =
a=20
warranty from a<BR>CA".<BR><BR>Does this mean that a relying party must =
have a=20
contract with the CA to get<BR>advantage of the warranty ?<BR>[Alice]=20
No.<BR><BR>Does this mean that a relying party will get a warranty =
without a=20
contract<BR>signed with the CA ?<BR>[Alice] Yes.<BR><BR>Does this =
extension=20
allow to make the difference between the case of a<BR>signed contract =
and the=20
case of an unsigned contract where the guarantees<BR>could be=20
different?<BR><BR>[Alice] No. If there are any differences in the =
T&amp;C=20
pertaining to a<BR>contractual arrangement, these differences will be =
outside=20
of, beyond the<BR>scope, and not pertinent to, the warranty offered in =
the=20
certificate.&nbsp; It<BR>applies equally to all relying parties, whether =
or not=20
a contract has been<BR>signed.<BR><BR>[Denis] Then say something like: =
"Whether=20
or not relying parties have signed<BR>agreements with CAs, the CA will =
provide=20
Terms and Conditions for this<BR>warranty which relates to its=20
liability."</FONT></P>
<P><FONT size=3D2>[AS2] Alternatively, to make the same point, it could =
remain=20
implicit. <BR><BR>2 - The difference between the base warranty and the =
extended=20
warranty is<BR>not crystal clear.<BR><BR>How can a relying party know =
whether it=20
can have the benefits of the base<BR>warranty or of the extended =
warranty=20
?<BR><BR>If the extended warranty is present, then the relying party has =
the=20
benefit<BR>of the extended warranty.&nbsp; In short, if it is present, =
then the=20
relying<BR>party knows that the relying party has the benefit of the =
extended=20
warranty<BR>by its presence alone.&nbsp; The syntax shows that the =
extended=20
warranty MAY be<BR>present:<BR>&nbsp; Warranty ::=3D CHOICE&nbsp;=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
none&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
NULL,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- No=20
warranty provided<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
wData&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
WarrantyData&nbsp; }&nbsp; -- Explicit =
warranty<BR><BR>&nbsp;&nbsp;&nbsp;=20
WarrantyData ::=3D SEQUENCE&nbsp; =
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
base&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
WarrantyInfo,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
extended&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
WarrantyInfo OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
tcURL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
TermsAndConditionsURL OPTIONAL&nbsp; }<BR><BR>If the tcURL is present, a =
human=20
being might understand the terms and<BR>conditions (if he can understand =
the=20
local language used), but a computer<BR>program will not be able to do =
so. This=20
means that computers cannot<BR>understand the difference.<BR><BR>[Alice] =
The=20
computer does not need to know what is in the T&amp;C.&nbsp; If the =
tcURL<BR>is=20
present, it is optionally for the benefit of the human reader. =
Perhaps<BR>you=20
could suggest some text to clarify this in the I-D if you still think =
it<BR>is=20
needed.<BR><BR>[Denis] Then say something like: "Warranty extensions are =
only=20
aimed for<BR>human interpretation and contain data that is inappropriate =
for=20
computer<BR>based verification schemes, the warranty extension MUST NOT =
be an=20
active<BR>component in automated certification path =
validation."</FONT></P>
<P><FONT size=3D2>[AS2] But this is not necessarily true. It may be that =
the RP=20
(i.e., the human) has to go to a T&amp;C document if the extended =
warranty is=20
present, if the RP wants to know what exactly is in the T&amp;C, but =
there=20
should be the option of not going to the T&amp;C.&nbsp; If the extended =
warranty=20
is not present (as noted in the syntax, it is optional), then there is =
no reason=20
that the extension could not be processed by the computer. Therefore, =
the=20
warranty extension is NOT "only aimed for human =
interpretation...".&nbsp; This=20
may be irrelevant to the point of automated certificate path validation, =
because=20
the extension is non-critical. <BR><BR>3 - There is no security on the=20
information placed at the tcURL parameter<BR>since no hash of the terms =
and=20
conditions is being used. These conditions<BR>could change overtime and =
relying=20
parties would not be able to demonstrate<BR>that they have=20
changed.<BR><BR>[Alice]<BR>It seems to me that the time stamp on the =
certificate=20
would suffice to place<BR>the warranty in a point of time at which the =
specified=20
terms and conditions<BR>applied; there is no need for the extension to=20
demonstrate that as this is<BR>covered by the certificate itself.&nbsp; =
This is=20
no different from the<BR>paper-based world in that if an insurance =
policy=20
changes its terms, it<BR>cannot do so retroactively to the detriment of =
clients=20
who have paid for a<BR>specific coverage, unless it notified the clients =
and=20
compensates them<BR>accordingly.<BR><BR>[Denis] The problem is that the =
CA could=20
change the policy and the relying<BR>party will be unable to demonstrate =
that=20
the policy has changed. A<BR>time-stamp token over the certificate would =
not=20
help. A time-stamp token<BR>over the T&amp;C would help, but the relying =
party=20
does not necessarily have<BR>access to one TSU. The hash approach is =
much=20
simpler.</FONT></P>
<P><FONT size=3D2>[AS2] A hash function on the T&amp;C? <BR><BR>4 - Is =
the=20
"Relying party Agreement" a document to signed by the parties or<BR>not =
? This=20
should be said.<BR><BR>[Alice]<BR>Use of the term "Relying Party =
Agreement" is=20
no different from its normal<BR>usage, just as "Certificate Policy" is =
used in=20
the same context without any<BR>change to the meaning from normal usage, =
as per=20
RFC 2527 and its successor.<BR>In other words, defining the terms, =
either=20
Relying Party Agreement or<BR>Certificate Policy is not necessary to the =

understanding of this extension.<BR><BR>[Denis] The term "Relying Party=20
Agreement" is confusing. Use a wording like<BR>"Terms and Conditions for =
Relying=20
parties" which does not imply that there<BR>is an agreement signed but =
that=20
unilaterally the CA provides terms and<BR>conditions. Relying parties =
may like=20
them or not. If they disagree with<BR>them, then this is still "Terms =
and=20
Conditions for Relying parties".</FONT></P>
<P><FONT size=3D2>[AS2] Maybe so, but the RP has the option of not using =
or=20
relying on the certificate. As I said before, this is normal =
terminology, and=20
should not be confusing; it is not being used with a different meaning.=20
<BR><BR>5 - The WarrantyValidityPeriod is insufficient. Usually there is =
a=20
period to<BR>claim for a compensation which must be made X months or Y =
days=20
after the<BR>date of the event which created the damage. It is thus not =
possible=20
to ask<BR>for a warranty during e.g. the whole validity period of the=20
certificate.<BR>Another time period parameter is =
missing.<BR><BR>[Alice]<BR>This=20
is exactly what the validity period is stating: that the warranty =
is<BR>valid=20
for a specified time, which is either the validity period of =
the<BR>certificate,=20
or another, specified time using the parameters as defined in<BR>the =
I-D.&nbsp;=20
It is presented and offered this way, so there is no need for<BR>another =

validity parameter.&nbsp; If an offeror wanted to specify a time =
within<BR>which=20
claims could be made, then a shorter time period than the validity =
of<BR>the=20
certificate can be used.&nbsp; This is unlike the paper-based world in=20
the<BR>sense that insurance policies are normally of long duration, =
whereas=20
this<BR>extension is associated with a certificate that normally has a =
validity=20
of<BR>two-three years.<BR><BR>[Denis] The semantics of the warranty =
validity=20
period is not defined ! There<BR>is a need to define more precisely what =
"the=20
warranty validity period" is.<BR>Here is a proposal along my original =
text. If=20
it does not fit, please<BR>propose an alternative:<BR><BR>" The warranty =

validity period is a time period to claim for a compensation<BR>which =
must be=20
made X months or Y days after the date of the event which<BR>created the =
damage.=20
It is unrelated to the certificate validity period."</FONT></P>
<P><FONT size=3D2>[AS2] What if the warranty validity period is indeed =
the same as=20
the certificate validity period? This was the scenario assumed to be =
most=20
likely, as it is stated in s.2.2, and therefore the option was created =
to allow=20
for a reduction in size of the extension by having NULL in warranty =
validity=20
period in the case where it was the same as the certificate validity=20
period.&nbsp; When it is not the same as the certificate validity =
period, then=20
the parameters available for warranty validity period can be used.&nbsp; =

<BR><BR>6 - The wType offers only two types of warranty: aggregated and=20
per<BR>transaction.<BR><BR>"Aggregated" means that that once the value =
of the=20
fulfilled claims reaches<BR>the maximum warranty amount, then no further =
claim=20
will be fulfilled.<BR><BR>"Per transaction" means that each claim is =
handled=20
independently but no<BR>individual claim can exceed the maximum warranty =

amount.<BR><BR>Each type has its own problems:<BR><BR>"Aggregated" is =
like a=20
race where late claimants will get no compensation at<BR>all because =
they were=20
not "fast enough". It is questionable whether such a<BR>race condition =
will be=20
acceptable.<BR>It should be understood that aggregation applies to one =
warranty=20
and one<BR>claimant.&nbsp; This is analogous to the paper-based =
world.&nbsp;=20
When you are covered<BR>by warranty for X product or service, e.g., =
health=20
insurance, there is often<BR>an upper limit (viz. the "value") up to =
which=20
claims will be met for each<BR>claimant; i.e., one insured =
person.<BR>"Per=20
transaction" means that the CA cannot compute the maximum amount =
of<BR>money=20
that it may have to give away. Which insurance company will =
ever<BR>insure a=20
risk for which an upper limit cannot be computed ?<BR><BR>[Alice]<BR>The =

T&amp;C, as noted in section 1, as covered by insurance, will specify=20
the<BR>maximum. The type of warranty selected depends on the nature of=20
the<BR>transactions, the parties to the transactions (e.g., individuals, =

large<BR>institutions, etc.).<BR><BR>[Denis] What I am asking for is to =
allow a=20
combination of both types, which<BR>is currently not possible. See below =

again.<BR><BR>None of these schemes is acceptable. Some combination =
should be=20
allowed:<BR><BR>&nbsp;&nbsp; - a maximum amount per transaction,=20
and<BR>&nbsp;&nbsp; - a maximum amount per certificate with a maximum =
time=20
period<BR>&nbsp;&nbsp;&nbsp;&nbsp; to claim for a compensation after the =
date of=20
the event<BR>&nbsp;&nbsp;&nbsp;&nbsp; (no race problem =
implied).</FONT></P>
<P><FONT size=3D2>[AS2] You have a good point. We may need some =
clarification in=20
s.2.2 to explain&nbsp;<SPAN class=3D756592221-12082003>exactly what=20
the</SPAN>&nbsp;currency amount means.&nbsp; This is clearly stated (and =

obvious) with respect to aggregate, but not so with =
per-transaction.&nbsp; It=20
should be indicated that there will be a maximum total of =
per-transaction=20
claims, which would be standard practice, and necessary for the ongoing =
health=20
of the CA.&nbsp;&nbsp;The total warranty offered for per-transaction=20
claims&nbsp;<SPAN class=3D756592221-12082003>could be expressed =
as</SPAN><SPAN=20
class=3D756592221-12082003> a new parameter indicating&nbsp;number of=20
per-transaction claims&nbsp;before the maximum would br reached, which =
would be=20
simple to calculate since the per-transaction maximum is stated; =
e.g.,&nbsp;a=20
sub-line after the per-transaction type code, number of transactions as =
a=20
maximum. </SPAN><BR><BR>7 - The content of the security consideration =
should be=20
augmented to<BR>indicate the difference between what a computer program =
can do=20
and a human<BR>being can do with this extension.<BR><BR>[Alice]<BR>I =
would have=20
thought this to be blindingly obvious.&nbsp; We would, however, =
be<BR>quite=20
willing to consider some proposed words to address this, if you =
do<BR>think it=20
is necessary.<BR><BR>[Denis] If my text proposal related to comment 2 is =

inserted, then this is<BR>no more needed.</FONT></P>
<P><FONT size=3D2>[AS2] Still willing to consider a proposal, but as you =
can see=20
from my response to your comments on point 2, I don't think this is =
quite right.=20
<BR><BR>8 - The document is not mature enough and its added value is=20
still<BR>questionable.<BR><BR>[Alice]<BR>We believe that it is =
mature.&nbsp; Its=20
value may be questionable to those who do<BR>not want to use it, but =
given that=20
it is (a) proposed as Informational and<BR>(b) always non-critical, =
surely its=20
availability for use is innocuous for<BR>those that do not want to use =
it.&nbsp;=20
For those who do want to use it, and we<BR>have heard from quite a =
number who=20
do, it will be useful and valuable.&nbsp; As<BR>in section 1: "When a=20
certificate contains a warranty certificate extension,<BR>the extension =
MUST be=20
non-critical, ..."<BR><BR>[Denis]<BR>As you can see, we have progressed, =
but=20
several issues still need to be<BR>addressed.</FONT></P>
<P><FONT size=3D2>[AS2] Yes<SPAN class=3D756592221-12082003>, we have =
made progress.=20
</SPAN>&nbsp;<BR><BR><BR>Denis<BR><BR><BR></FONT></P></BODY></HTML>

------=_NextPart_000_0000_01C36161.8B1E5A10--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CMLRqt008556 for <[e-mail]>; Tue, 12 Aug 2003 15:21:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CMLRtY008555 for ietf-pkix-bks; Tue, 12 Aug 2003 15:21:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CMLOqt008533 for <[e-mail]>; Tue, 12 Aug 2003 15:21:24 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (56.sanjose-01-02rs16rt.ca.dial-access.att.net[12.81.0.56]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003081222211711300cvjgce>; Tue, 12 Aug 2003 22:21:18 +0000
Message-ID: <005801c36120$0c2b06e0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Hallam-Baker, Phillip" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Tue, 12 Aug 2003 15:21:08 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Phillip -
----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, August 12, 2003 12:41 PM
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)


>
> > Bill Joy (why is it always people named "Bill" who cause these
> > problems?) decided that the cost of computing the TCP checksum was
> > high and resulted in diminished throughout, and besides, in the
> > typical Ethernet LAN context, the CRC caught errors anyway. So, for a
> > while BSD didn't bother computing the checksum, at least if it could
> > detect that the peer implementation was another BSD system. DARPA,
> > who was funding this work, had to bring significant pressure to bear,
> > to quash this behavior.
>
> I would just like to observe that at this point DARPA does not have the
> ability to bring significant pressure to bear, nor for that matter does
the
> IESG.
>

Maybe not but the Homeland Defense folks do as does the DoJ...

> The fundamental problem of the IETF is that it continues to act as if it
was
> in a position to act in a unilateral and unaccountable fashion and have
> DARPA or the market enforce its decisions when in fact those days are long
> gone.

When DARPA or NSF ran the "net" there was no amount of commerce on it worth
commenting over...

>
> I do not have a particular problem with the way Stephen is chairing this
> group.

lets not go there.

> I do however have a big problem with the IETF generally and the
> chair's prerogatives which Stephen is arguing for.

I Support this as the core problem with the IESG's so called "standards
process" - it and the IETF is essentially a Guild and not anything like
"accountable for what it does" and that is the key issue here.

>
> Stephen is entirely right about the way that the IETF works, according to
> the rules the chair can behave in any damn way he wants. The chair is
> completely free to ignore the decisions of the group and impose his own.
> That is exactly what happened in the case of DNSEXT. There is no question
> that the IETF can continue to run itself on the 'magic circle' principle
if
> it chooses.
>
> The corollary is that the industry can decide to go its own way and ignore
> the work product of this group in particular and the IETF in general. The
> magic circle principle fails if it excludes the major stakeholders. At
this
> point there is only one major vendor which is still engaged in IETF in a
> meaningful way.
>
> Complain about industry not implementing standards if you will. But why do
> you expect people to implement specifications when they are excluded from
> the decision making process?
>
> My problem with the IETF is that it is completely ineffective in building
> consensus amongst the stakeholders. Taking a proposal to the IETF will not
> get buy in from my business partners or my competitors. All it will
achieve
> is a delay of two to three years in which the exact status of the proposal
> will be uncertain.
>
> My strong recommendation is to simply approve all existing drafts in their
> current state and close. Whether the drafts are correct or not is
irrelevant
> at this point as is the question of whether they do or do not describe
real
> world practice.
>
> And before Stephen gets too upset here, I am referring to the IETF as a
> whole and not just the PKIX group.
>
>
> Phill



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CJg3qt097188 for <[e-mail]>; Tue, 12 Aug 2003 12:42:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CJg3r3097187 for ietf-pkix-bks; Tue, 12 Aug 2003 12:42:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CJg1qt097182 for <[e-mail]>; Tue, 12 Aug 2003 12:42:01 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h7CJfhim013961; Tue, 12 Aug 2003 12:41:43 -0700 (PDT)
Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <QQ0HXVDP>; Tue, 12 Aug 2003 12:41:43 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Tue, 12 Aug 2003 12:41:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Bill Joy (why is it always people named "Bill" who cause these 
> problems?) decided that the cost of computing the TCP checksum was 
> high and resulted in diminished throughout, and besides, in the 
> typical Ethernet LAN context, the CRC caught errors anyway. So, for a 
> while BSD didn't bother computing the checksum, at least if it could 
> detect that the peer implementation was another BSD system. DARPA, 
> who was funding this work, had to bring significant pressure to bear, 
> to quash this behavior.

I would just like to observe that at this point DARPA does not have the
ability to bring significant pressure to bear, nor for that matter does the
IESG.

The fundamental problem of the IETF is that it continues to act as if it was
in a position to act in a unilateral and unaccountable fashion and have
DARPA or the market enforce its decisions when in fact those days are long
gone.

I do not have a particular problem with the way Stephen is chairing this
group.  I do however have a big problem with the IETF generally and the
chair's prerogatives which Stephen is arguing for. 

Stephen is entirely right about the way that the IETF works, according to
the rules the chair can behave in any damn way he wants. The chair is
completely free to ignore the decisions of the group and impose his own.
That is exactly what happened in the case of DNSEXT. There is no question
that the IETF can continue to run itself on the 'magic circle' principle if
it chooses.

The corollary is that the industry can decide to go its own way and ignore
the work product of this group in particular and the IETF in general. The
magic circle principle fails if it excludes the major stakeholders. At this
point there is only one major vendor which is still engaged in IETF in a
meaningful way.

Complain about industry not implementing standards if you will. But why do
you expect people to implement specifications when they are excluded from
the decision making process?

My problem with the IETF is that it is completely ineffective in building
consensus amongst the stakeholders. Taking a proposal to the IETF will not
get buy in from my business partners or my competitors. All it will achieve
is a delay of two to three years in which the exact status of the proposal
will be uncertain. 

My strong recommendation is to simply approve all existing drafts in their
current state and close. Whether the drafts are correct or not is irrelevant
at this point as is the question of whether they do or do not describe real
world practice. 

And before Stephen gets too upset here, I am referring to the IETF as a
whole and not just the PKIX group.


		Phill


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CIqhqt095081 for <[e-mail]>; Tue, 12 Aug 2003 11:52:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CIqh1G095080 for ietf-pkix-bks; Tue, 12 Aug 2003 11:52:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CIqgqt095073 for <[e-mail]>; Tue, 12 Aug 2003 11:52:42 -0700 (PDT)
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 90119206607 for <[e-mail]>; Tue, 12 Aug 2003 14:51:11 -0400 (EDT)
Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19me99-0006A3-FR for [e-mail]; Tue, 12 Aug 2003 14:45:27 -0400
Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19me7r-0005yz-8u; Tue, 12 Aug 2003 14:44:07 -0400
X-test-idtracker: no
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Last Call: 'Internet X.509 Public Key Infrastructure Warranty  Certificate Extension' to Informational RFC 
Reply-To: [e-mail]
Message-Id: <[e-mail]>
Date: Tue, 12 Aug 2003 14:44:07 -0400
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2003-08-26.
                                                                                       
File(s) can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-03.txt




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CIjQqt094715 for <[e-mail]>; Tue, 12 Aug 2003 11:45:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CIjQXj094714 for ietf-pkix-bks; Tue, 12 Aug 2003 11:45:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CIjPqt094708 for <[e-mail]>; Tue, 12 Aug 2003 11:45:25 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19me7r-0005yz-8u; Tue, 12 Aug 2003 14:44:07 -0400
X-test-idtracker: no
To: IETF-Announce :;
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Last Call: 'Internet X.509 Public Key Infrastructure Warranty  Certificate Extension' to Informational RFC 
Reply-to: [e-mail]
Message-Id: <[e-mail]>
Date: Tue, 12 Aug 2003 14:44:07 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2003-08-26.
                                                                                       
File(s) can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-03.txt



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BK4Bqt070147 for <[e-mail]>; Mon, 11 Aug 2003 13:04:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BK4BiM070146 for ietf-pkix-bks; Mon, 11 Aug 2003 13:04:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BK49qt070136 for <[e-mail]>; Mon, 11 Aug 2003 13:04:10 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19mIrq-0005I7-V1; Mon, 11 Aug 2003 16:02:10 -0400
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, <[e-mail]>
Subject: Document Action: 'Policy Requirements for Time-Stamping  Authorities' to Informational RFC 
Message-Id: <[e-mail]>
Date: Mon, 11 Aug 2003 16:02:10 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Policy Requirements for 
Time-Stamping Authorities' <draft-ietf-pkix-pr-tsa-05.txt> as an 
Informational RFC. This document is the product of the Public-Key 
Infrastructure (X.509) Working Group. The IESG contact persons are Russ 
Housley and Steve Bellovin.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h799ccqt005704 for <[e-mail]>; Sat, 9 Aug 2003 02:38:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h799caGp005702 for ietf-pkix-bks; Sat, 9 Aug 2003 02:38:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from klapautius.it.su.se (as13-3-2.rny.s.bonet.se [217.215.166.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h799cPqt005695 for <[e-mail]>; Sat, 9 Aug 2003 02:38:32 -0700 (PDT) (envelope-from [e-mail])
Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h799c6215090; Sat, 9 Aug 2003 11:38:13 +0200
Message-ID: <[e-mail]>
Date: Sat, 09 Aug 2003 11:38:05 +0200
From: Leif Johansson <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: [e-mail], "'PKIX'" <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
References: <001e01c357e3$61e70a70$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Chadwick wrote:

<snip>

>different RDNs, containing the same attribute. But this is not a real
>problem is it? They can be configured to ignore the child entries since
>these DNs wont match the DNs in the certificates. How long the problem
>will persist will depend upon how quickly implementors move from the
>extraction mechanism to the direct matching mechanism.
>  
>
You assume that directory dn structure and certificate dn structure 
match in
general. That sounds like a pretty big assumption to me.

       Cheers Leif



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78KSRqt050494 for <[e-mail]>; Fri, 8 Aug 2003 13:28:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78KSRnj050493 for ietf-pkix-bks; Fri, 8 Aug 2003 13:28:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from klapautius.it.su.se (as13-3-2.rny.s.bonet.se [217.215.166.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78KSMqt050485 for <[e-mail]>; Fri, 8 Aug 2003 13:28:24 -0700 (PDT) (envelope-from [e-mail])
Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h78KS6211386; Fri, 8 Aug 2003 22:28:06 +0200
Message-ID: <[e-mail]>
Date: Fri, 08 Aug 2003 22:28:05 +0200
From: Leif Johansson <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
References: <[e-mail]> <[e-mail]> <p05210600bb4ad9ed31e9@[128.89.89.75]> <[e-mail]> <p05210605bb4aec47262b@[128.89.89.75]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Chadwick wrote:

>Leif
>
>The main problem is that some LDAP vendors have not implemented basic
>LDAP, but have subtracted some features from the LDAP standard that they
>the vendors (but not their users) did not see a need for, such as
>aliases, multi-valued RDNs, DIT structure rules and name forms, matching
>rules etc. The PKIX group is wanting to use standard features from LDAP,
>not extensions (and LDAP has defined plenty of those itself) or add ons.
>
>regards
>
>  
>
Hmmm, standards in the ietf are defined by running code. If, in the 
course of
deploying a standard certain features are not implemented or not implemented
consistently those features must go away. Fundamentally the market decides
what ietf standards are worth implementing. The pkix wg can no more than
any other part of the ietf mandate what gets implemented or not.

       MVH leifj



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Ex9qt025894 for <[e-mail]>; Thu, 7 Aug 2003 07:59:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77Ex96U025893 for ietf-pkix-bks; Thu, 7 Aug 2003 07:59:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77Ex7qt025884 for <[e-mail]>; Thu, 7 Aug 2003 07:59:07 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA20539 for <[e-mail]>; Thu, 7 Aug 2003 16:59:07 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 7 Aug 2003 16:59:07 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h77Ex6B13663 for [e-mail]; Thu, 7 Aug 2003 16:59:06 +0200 (MEST)
Date: Thu, 7 Aug 2003 16:59:06 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: first comments for SCVP 12
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here some more comments. 

After having read the conversation between trevor and Denis
concerning validation policies, i'd like to see asap the
next textual proposal. 

I believe that the current text of SCVP is difficult to implement
if I remember correctly how to use ASN1.

for data structures that are using some types like

   SEQUENCE {type OID, parm ANY DEFINED BY type} 

the complete list of known ids (like the default or the
name policy) need to be defined in advance and complied into
the code. 

On the other hand the requirements doc and SCVP specify that
the valPolicy identifies a configuration. A configuration
can contain for example trust anchors. one would at least have
to define in the client some cloning mechanism to identify
different settings of trust anchors in a dynamic way 
suited for a particular client context. 

The configuration of the client would be something like:

-  an OID identifying the agreed context/configuration

-  an rule allowing to code one or more "validation policy parameters"
  for the validation policy (ies) which are part of the particular 
  configuration identified by a configuration OID.
  
If we remember a structure like: 

PolicyInformation ::= SEQUENCE {

     policyIdentifier   CertPolicyId,
     policyQualifiers   SEQUENCE SIZE (1..MAX) OF
             PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {
       policyQualifierId  PolicyQualifierId,
       qualifier        ANY DEFINED BY policyQualifierId }

one would define additional values for PolicyQualifierId
for the default policy and the name policy. 

It is getting really hot here.
Peter


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77EXFqt022197 for <[e-mail]>; Thu, 7 Aug 2003 07:33:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77EXFwT022196 for ietf-pkix-bks; Thu, 7 Aug 2003 07:33:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77EXEqt022178 for <[e-mail]>; Thu, 7 Aug 2003 07:33:14 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V77E0TPA03035 for <[e-mail]>; Thu, 07 Aug 2003 10:29:25 -0400
Received: (qmail 32696 invoked by uid 64014); 7 Aug 2003 14:26:14 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.871647 secs); 07 Aug 2003 14:26:14 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by 10.4.61.249 with SMTP; 7 Aug 2003 14:26:13 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <QMF1Y1T7>; Thu, 7 Aug 2003 10:33:07 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "Steve Hanna (E-mail)" <[e-mail]>, "pkix (E-mail)" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: FW:Resend  PKIX LDAPv3 schema: component matching or separate ent ries
Date: Thu, 7 Aug 2003 10:33:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve I certainly share your concerns. I don't believe existing 
deployed systems will modify their schema. They are working just 
fine the way they are and have no reason to change. Also, from 
an interoperability standpoint I expect great reluctance to move 
to the schema in real world deployments that need to interop with 
existing ones using the old schema.

Sharon

-----Original Message-----
From: Steve Hanna [mailto:[e-mail]]
Sent: Tuesday, August 05, 2003 3:21 PM
To: PKIX List; [e-mail]
Subject: PKIX LDAPv3 schema: component matching or separate entries


The draft minutes from the IETF 57 PKIX WG meeting say:

> LDAP Documents: - David Chadwick (Univ of Salford) & Peter Gietz
>                (DAASI)
> The WG has a suite of LDAP-PKIX drafts forming a comprehensive
> solution for LDAP based PKI information distribution.

I believe that the PK certificate schema is described in
draft-klasen-ldap-x509certificate-schema-03.txt.

That document (and the CRL and AC schemas) proposes a
change from storing certificates in the multi-valued
userCertificate and cACertificate attributes of an
entity's directory entry to storing certificates as
separate directory entries, subordinate to the entity's
directory entry. Values may then be extracted from
certificate fields and placed in attributes on the
certificate's directory entry so that it's easier to
search for certificates and retrieve only those you want.

At IETF 56, there was a discussion about whether to make
this change or stick with the current schema and use
component matching to solve the problem. As noted in the
meeting minutes, a straw poll favored component matching
but it was agreed to take this discussion to the mailing
list. I haven't seen any discussion on the mailing list,
but now it seems that the matter has been decided in favor
of the modified schema.

Did I miss something? Was this discussed and agreed to on
the mailing list? If not, it should be discussed here.

I would like to hear from customers who are using the old
schema as to whether they will be happy moving to the new
schema. I'm concerned that they may be reluctant to double
or triple the number of entries in their directory.

Thanks,

Steve Hanna


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77DhKqt019286 for <[e-mail]>; Thu, 7 Aug 2003 06:43:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77DhK6v019285 for ietf-pkix-bks; Thu, 7 Aug 2003 06:43:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77DhIqt019259 for <[e-mail]>; Thu, 7 Aug 2003 06:43:19 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V77D23SA28485 for <[e-mail]>; Thu, 07 Aug 2003 09:39:28 -0400
Received: (qmail 22532 invoked by uid 64014); 7 Aug 2003 13:36:18 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.117366 secs); 07 Aug 2003 13:36:18 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 7 Aug 2003 13:36:18 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <QMF1YDDN>; Thu, 7 Aug 2003 09:43:12 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, PKIX List <[e-mail]>, [e-mail]
Subject: RE: PKIX LDAPv3 schema: component matching or separate entries
Date: Thu, 7 Aug 2003 09:43:12 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

MIInNAYJKoZIhvcNAQcCoIInJTCCJyECAQExCzAJBgUrDgMCGgUAMIIZggYJKoZIhvcNAQcBoIIZ
cwSCGW9Db250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2ZTsNCglib3VuZGFyeT0iLS09
X05leHRQYXJ0X1NUSl84ODczOTk2OC4wOTQ1NDI3MTQiDQoNCg0KLS0tLT1fTmV4dFBhcnRfU1RK
Xzg4NzM5OTY4LjA5NDU0MjcxNA0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9
IlVTLUFTQ0lJIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0K
DQpTdGV2ZSBJIGNlcnRhaW5seSBzaGFyZSB5b3VyIGNvbmNlcm5zLiBJIGRvbid0IGJlbGlldmUg
ZXhpc3Rpbmc9MjANCmRlcGxveWVkIHN5c3RlbXMgd2lsbCBtb2RpZnkgdGhlaXIgc2NoZW1hLiBU
aGV5IGFyZSB3b3JraW5nIGp1c3Q9MjANCmZpbmUgdGhlIHdheSB0aGV5IGFyZSBhbmQgaGF2ZSBu
byByZWFzb24gdG8gY2hhbmdlLiBBbHNvLCBmcm9tPTIwDQphbiBpbnRlcm9wZXJhYmlsaXR5IHN0
YW5kcG9pbnQgSSBleHBlY3QgZ3JlYXQgcmVsdWN0YW5jZSB0byBtb3ZlPTIwDQp0byB0aGUgc2No
ZW1hIGluIHJlYWwgd29ybGQgZGVwbG95bWVudHMgdGhhdCBuZWVkIHRvIGludGVyb3Agd2l0aD0y
MA0KZXhpc3Rpbmcgb25lcyB1c2luZyB0aGUgb2xkIHNjaGVtYS4NCg0KU2hhcm9uDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGV2ZSBIYW5uYSA9NUJtYWlsdG86c3RldmUu
aGFubmE9NDBzdW4uY29tPTVEDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDUsIDIwMDMgMzoyMSBQ
TQ0KVG86IFBLSVggTGlzdDsgaWV0Zi1sZGFwYmlzPTQwT3BlbkxEQVAub3JnDQpTdWJqZWN0OiBQ
S0lYIExEQVB2MyBzY2hlbWE6IGNvbXBvbmVudCBtYXRjaGluZyBvciBzZXBhcmF0ZSBlbnRyaWVz
DQoNCg0KVGhlIGRyYWZ0IG1pbnV0ZXMgZnJvbSB0aGUgSUVURiA1NyBQS0lYIFdHIG1lZXRpbmcg
c2F5Og0KDQo+IExEQVAgRG9jdW1lbnRzOiAtIERhdmlkIENoYWR3aWNrIChVbml2IG9mIFNhbGZv
cmQpICYgUGV0ZXIgR2lldHoNCj4gICAgICAgICAgICAgICAgKERBQVNJKQ0KPiBUaGUgV0cgaGFz
IGEgc3VpdGUgb2YgTERBUC1QS0lYIGRyYWZ0cyBmb3JtaW5nIGEgY29tcHJlaGVuc2l2ZQ0KPiBz
b2x1dGlvbiBmb3IgTERBUCBiYXNlZCBQS0kgaW5mb3JtYXRpb24gZGlzdHJpYnV0aW9uLg0KDQpJ
IGJlbGlldmUgdGhhdCB0aGUgUEsgY2VydGlmaWNhdGUgc2NoZW1hIGlzIGRlc2NyaWJlZCBpbg0K
ZHJhZnQta2xhc2VuLWxkYXAteDUwOWNlcnRpZmljYXRlLXNjaGVtYS0wMy50eHQuDQoNClRoYXQg
ZG9jdW1lbnQgKGFuZCB0aGUgQ1JMIGFuZCBBQyBzY2hlbWFzKSBwcm9wb3NlcyBhDQpjaGFuZ2Ug
ZnJvbSBzdG9yaW5nIGNlcnRpZmljYXRlcyBpbiB0aGUgbXVsdGktdmFsdWVkDQp1c2VyQ2VydGlm
aWNhdGUgYW5kIGNBQ2VydGlmaWNhdGUgYXR0cmlidXRlcyBvZiBhbg0KZW50aXR5J3MgZGlyZWN0
b3J5IGVudHJ5IHRvIHN0b3JpbmcgY2VydGlmaWNhdGVzIGFzDQpzZXBhcmF0ZSBkaXJlY3Rvcnkg
ZW50cmllcywgc3Vib3JkaW5hdGUgdG8gdGhlIGVudGl0eSdzDQpkaXJlY3RvcnkgZW50cnkuIFZh
bHVlcyBtYXkgdGhlbiBiZSBleHRyYWN0ZWQgZnJvbQ0KY2VydGlmaWNhdGUgZmllbGRzIGFuZCBw
bGFjZWQgaW4gYXR0cmlidXRlcyBvbiB0aGUNCmNlcnRpZmljYXRlJ3MgZGlyZWN0b3J5IGVudHJ5
IHNvIHRoYXQgaXQncyBlYXNpZXIgdG8NCnNlYXJjaCBmb3IgY2VydGlmaWNhdGVzIGFuZCByZXRy
aWV2ZSBvbmx5IHRob3NlIHlvdSB3YW50Lg0KDQpBdCBJRVRGIDU2LCB0aGVyZSB3YXMgYSBkaXNj
dXNzaW9uIGFib3V0IHdoZXRoZXIgdG8gbWFrZQ0KdGhpcyBjaGFuZ2Ugb3Igc3RpY2sgd2l0aCB0
aGUgY3VycmVudCBzY2hlbWEgYW5kIHVzZQ0KY29tcG9uZW50IG1hdGNoaW5nIHRvIHNvbHZlIHRo
ZSBwcm9ibGVtLiBBcyBub3RlZCBpbiB0aGUNCm1lZXRpbmcgbWludXRlcywgYSBzdHJhdyBwb2xs
IGZhdm9yZWQgY29tcG9uZW50IG1hdGNoaW5nDQpidXQgaXQgd2FzIGFncmVlZCB0byB0YWtlIHRo
aXMgZGlzY3Vzc2lvbiB0byB0aGUgbWFpbGluZw0KbGlzdC4gSSBoYXZlbid0IHNlZW4gYW55IGRp
c2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCwNCmJ1dCBub3cgaXQgc2VlbXMgdGhhdCB0aGUg
bWF0dGVyIGhhcyBiZWVuIGRlY2lkZWQgaW4gZmF2b3INCm9mIHRoZSBtb2RpZmllZCBzY2hlbWEu
DQoNCkRpZCBJIG1pc3Mgc29tZXRoaW5nPyBXYXMgdGhpcyBkaXNjdXNzZWQgYW5kIGFncmVlZCB0
byBvbg0KdGhlIG1haWxpbmcgbGlzdD8gSWYgbm90LCBpdCBzaG91bGQgYmUgZGlzY3Vzc2VkIGhl
cmUuDQoNCkkgd291bGQgbGlrZSB0byBoZWFyIGZyb20gY3VzdG9tZXJzIHdobyBhcmUgdXNpbmcg
dGhlIG9sZA0Kc2NoZW1hIGFzIHRvIHdoZXRoZXIgdGhleSB3aWxsIGJlIGhhcHB5IG1vdmluZyB0
byB0aGUgbmV3DQpzY2hlbWEuIEknbSBjb25jZXJuZWQgdGhhdCB0aGV5IG1heSBiZSByZWx1Y3Rh
bnQgdG8gZG91YmxlDQpvciB0cmlwbGUgdGhlIG51bWJlciBvZiBlbnRyaWVzIGluIHRoZWlyIGRp
cmVjdG9yeS4NCg0KVGhhbmtzLA0KDQpTdGV2ZSBIYW5uYQ0KDQotLS0tPV9OZXh0UGFydF9TVEpf
ODg3Mzk5NjguMDk0NTQyNzE0DQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3J0Zg0KQ29udGVu
dC1UcmFuc2Zlci1FbmNvZGluZzogYmFzZTY0DQoNCmUxeHlkR1l4WEdGdWMybGNZVzV6YVdOd1p6
RXlOVEpjWm5KdmJYUmxlSFFnWEdSbFptWXdlMXhtYjI1MGRHSnMNCkRRcDdYR1l3WEdaemQybHpj
eUJCY21saGJEdDlEUXA3WEdZeFhHWnRiMlJsY200Z1EyOTFjbWxsY2lCT1pYYzcNCmZRMEtlMXht
TWx4bWJtbHNYR1pqYUdGeWMyVjBNaUJUZVcxaWIydzdmUTBLZTF4bU0xeG1iVzlrWlhKdVhHWmoN
CmFHRnljMlYwTUNCRGIzVnlhV1Z5SUU1bGR6dDlmUTBLZTF4amIyeHZjblJpYkZ4eVpXUXdYR2R5
WldWdU1GeGkNCmJIVmxNRHRjY21Wa01GeG5jbVZsYmpCY1lteDFaVEkxTlR0OURRcGNkV014WEhC
aGNtUmNjR3hoYVc1Y1pHVm0NCmRHRmlNell3SUZ4bU1GeG1jekl3SUZOMFpYWmxJRWtnWTJWeWRH
RnBibXg1SUhOb1lYSmxJSGx2ZFhJZ1kyOXUNClkyVnlibk11SUVrZ1pHOXVKM1FnWW1Wc2FXVjJa
U0JsZUdsemRHbHVaeUJjY0dGeURRcGtaWEJzYjNsbFpDQnoNCmVYTjBaVzF6SUhkcGJHd2diVzlr
YVdaNUlIUm9aV2x5SUhOamFHVnRZUzRnVkdobGVTQmhjbVVnZDI5eWEybHUNClp5QnFkWE4wSUZ4
d1lYSU5DbVpwYm1VZ2RHaGxJSGRoZVNCMGFHVjVJR0Z5WlNCaGJtUWdhR0YyWlNCdWJ5QnkNClpX
RnpiMjRnZEc4Z1kyaGhibWRsTGlCQmJITnZMQ0JtY205dElGeHdZWElOQ21GdUlHbHVkR1Z5YjNC
bGNtRmkNCmFXeHBkSGtnYzNSaGJtUndiMmx1ZENCSklHVjRjR1ZqZENCbmNtVmhkQ0J5Wld4MVkz
UmhibU5sSUhSdklHMXYNCmRtVWdYSEJoY2cwS2RHOGdkR2hsSUhOamFHVnRZU0JwYmlCeVpXRnNJ
SGR2Y214a0lHUmxjR3h2ZVcxbGJuUnoNCklIUm9ZWFFnYm1WbFpDQjBieUJwYm5SbGNtOXdJSGRw
ZEdnZ1hIQmhjZzBLWlhocGMzUnBibWNnYjI1bGN5QjENCmMybHVaeUIwYUdVZ2IyeGtJSE5qYUdW
dFlTNWNjR0Z5RFFwY2NHRnlEUXBUYUdGeWIyNWNjR0Z5RFFwY2NHRnkNCkRRb3RMUzB0TFU5eWFX
ZHBibUZzSUUxbGMzTmhaMlV0TFMwdExWeHdZWElOQ2taeWIyMDZJRk4wWlhabElFaGgNCmJtNWhJ
RnR0WVdsc2RHODZjM1JsZG1VdWFHRnVibUZBYzNWdUxtTnZiVjFjY0dGeURRcFRaVzUwT2lCVWRX
VnoNClpHRjVMQ0JCZFdkMWMzUWdNRFVzSURJd01ETWdNem95TVNCUVRWeHdZWElOQ2xSdk9pQlFT
MGxZSUV4cGMzUTcNCklHbGxkR1l0YkdSaGNHSnBjMEJQY0dWdVRFUkJVQzV2Y21kY2NHRnlEUXBU
ZFdKcVpXTjBPaUJRUzBsWUlFeEUNClFWQjJNeUJ6WTJobGJXRTZJR052YlhCdmJtVnVkQ0J0WVhS
amFHbHVaeUJ2Y2lCelpYQmhjbUYwWlNCbGJuUnkNCmFXVnpYSEJoY2cwS1hIQmhjZzBLWEhCaGNn
MEtWR2hsSUdSeVlXWjBJRzFwYm5WMFpYTWdabkp2YlNCMGFHVWcNClNVVlVSaUExTnlCUVMwbFlJ
RmRISUcxbFpYUnBibWNnYzJGNU9seHdZWElOQ2x4d1lYSU5DajRnVEVSQlVDQkUNCmIyTjFiV1Z1
ZEhNNklDMGdSR0YyYVdRZ1EyaGhaSGRwWTJzZ0tGVnVhWFlnYjJZZ1UyRnNabTl5WkNrZ0ppQlEN
ClpYUmxjaUJIYVdWMGVseHdZWElOQ2o0Z0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnS0VSQlFWTkpLVnh3
WVhJTkNqNGcNClZHaGxJRmRISUdoaGN5QmhJSE4xYVhSbElHOW1JRXhFUVZBdFVFdEpXQ0JrY21G
bWRITWdabTl5YldsdVp5QmgNCklHTnZiWEJ5WldobGJuTnBkbVZjY0dGeURRbytJSE52YkhWMGFX
OXVJR1p2Y2lCTVJFRlFJR0poYzJWa0lGQkwNClNTQnBibVp2Y20xaGRHbHZiaUJrYVhOMGNtbGlk
WFJwYjI0dVhIQmhjZzBLWEhCaGNnMEtTU0JpWld4cFpYWmwNCklIUm9ZWFFnZEdobElGQkxJR05s
Y25ScFptbGpZWFJsSUhOamFHVnRZU0JwY3lCa1pYTmpjbWxpWldRZ2FXNWMNCmNHRnlEUXBrY21G
bWRDMXJiR0Z6Wlc0dGJHUmhjQzE0TlRBNVkyVnlkR2xtYVdOaGRHVXRjMk5vWlcxaExUQXoNCkxu
UjRkQzVjY0dGeURRcGNjR0Z5RFFwVWFHRjBJR1J2WTNWdFpXNTBJQ2hoYm1RZ2RHaGxJRU5TVENC
aGJtUWcNClFVTWdjMk5vWlcxaGN5a2djSEp2Y0c5elpYTWdZVnh3WVhJTkNtTm9ZVzVuWlNCbWNt
OXRJSE4wYjNKcGJtY2cNClkyVnlkR2xtYVdOaGRHVnpJR2x1SUhSb1pTQnRkV3gwYVMxMllXeDFa
V1JjY0dGeURRcDFjMlZ5UTJWeWRHbG0NCmFXTmhkR1VnWVc1a0lHTkJRMlZ5ZEdsbWFXTmhkR1Vn
WVhSMGNtbGlkWFJsY3lCdlppQmhibHh3WVhJTkNtVnUNCmRHbDBlU2R6SUdScGNtVmpkRzl5ZVNC
bGJuUnllU0IwYnlCemRHOXlhVzVuSUdObGNuUnBabWxqWVhSbGN5QmgNCmMxeHdZWElOQ25ObGNH
RnlZWFJsSUdScGNtVmpkRzl5ZVNCbGJuUnlhV1Z6TENCemRXSnZjbVJwYm1GMFpTQjANCmJ5QjBh
R1VnWlc1MGFYUjVKM05jY0dGeURRcGthWEpsWTNSdmNua2daVzUwY25rdUlGWmhiSFZsY3lCdFlY
a2cNCmRHaGxiaUJpWlNCbGVIUnlZV04wWldRZ1puSnZiVnh3WVhJTkNtTmxjblJwWm1sallYUmxJ
R1pwWld4a2N5QmgNCmJtUWdjR3hoWTJWa0lHbHVJR0YwZEhKcFluVjBaWE1nYjI0Z2RHaGxYSEJo
Y2cwS1kyVnlkR2xtYVdOaGRHVW4NCmN5QmthWEpsWTNSdmNua2daVzUwY25rZ2MyOGdkR2hoZENC
cGRDZHpJR1ZoYzJsbGNpQjBiMXh3WVhJTkNuTmwNCllYSmphQ0JtYjNJZ1kyVnlkR2xtYVdOaGRH
VnpJR0Z1WkNCeVpYUnlhV1YyWlNCdmJteDVJSFJvYjNObElIbHYNCmRTQjNZVzUwTGx4d1lYSU5D
bHh3WVhJTkNrRjBJRWxGVkVZZ05UWXNJSFJvWlhKbElIZGhjeUJoSUdScGMyTjENCmMzTnBiMjRn
WVdKdmRYUWdkMmhsZEdobGNpQjBieUJ0WVd0bFhIQmhjZzBLZEdocGN5QmphR0Z1WjJVZ2IzSWcN
CmMzUnBZMnNnZDJsMGFDQjBhR1VnWTNWeWNtVnVkQ0J6WTJobGJXRWdZVzVrSUhWelpWeHdZWElO
Q21OdmJYQnYNCmJtVnVkQ0J0WVhSamFHbHVaeUIwYnlCemIyeDJaU0IwYUdVZ2NISnZZbXhsYlM0
Z1FYTWdibTkwWldRZ2FXNGcNCmRHaGxYSEJoY2cwS2JXVmxkR2x1WnlCdGFXNTFkR1Z6TENCaElI
TjBjbUYzSUhCdmJHd2dabUYyYjNKbFpDQmoNCmIyMXdiMjVsYm5RZ2JXRjBZMmhwYm1kY2NHRnlE
UXBpZFhRZ2FYUWdkMkZ6SUdGbmNtVmxaQ0IwYnlCMFlXdGwNCklIUm9hWE1nWkdselkzVnpjMmx2
YmlCMGJ5QjBhR1VnYldGcGJHbHVaMXh3WVhJTkNteHBjM1F1SUVrZ2FHRjINClpXNG5kQ0J6WldW
dUlHRnVlU0JrYVhOamRYTnphVzl1SUc5dUlIUm9aU0J0WVdsc2FXNW5JR3hwYzNRc1hIQmgNCmNn
MEtZblYwSUc1dmR5QnBkQ0J6WldWdGN5QjBhR0YwSUhSb1pTQnRZWFIwWlhJZ2FHRnpJR0psWlc0
Z1pHVmoNCmFXUmxaQ0JwYmlCbVlYWnZjbHh3WVhJTkNtOW1JSFJvWlNCdGIyUnBabWxsWkNCelky
aGxiV0V1WEhCaGNnMEsNClhIQmhjZzBLUkdsa0lFa2diV2x6Y3lCemIyMWxkR2hwYm1jL0lGZGhj
eUIwYUdseklHUnBjMk4xYzNObFpDQmgNCmJtUWdZV2R5WldWa0lIUnZJRzl1WEhCaGNnMEtkR2hs
SUcxaGFXeHBibWNnYkdsemREOGdTV1lnYm05MExDQnANCmRDQnphRzkxYkdRZ1ltVWdaR2x6WTNW
emMyVmtJR2hsY21VdVhIQmhjZzBLWEhCaGNnMEtTU0IzYjNWc1pDQnMNCmFXdGxJSFJ2SUdobFlY
SWdabkp2YlNCamRYTjBiMjFsY25NZ2QyaHZJR0Z5WlNCMWMybHVaeUIwYUdVZ2IyeGsNClhIQmhj
ZzBLYzJOb1pXMWhJR0Z6SUhSdklIZG9aWFJvWlhJZ2RHaGxlU0IzYVd4c0lHSmxJR2hoY0hCNUlH
MXYNCmRtbHVaeUIwYnlCMGFHVWdibVYzWEhCaGNnMEtjMk5vWlcxaExpQkpKMjBnWTI5dVkyVnli
bVZrSUhSb1lYUWcNCmRHaGxlU0J0WVhrZ1ltVWdjbVZzZFdOMFlXNTBJSFJ2SUdSdmRXSnNaVnh3
WVhJTkNtOXlJSFJ5YVhCc1pTQjANCmFHVWdiblZ0WW1WeUlHOW1JR1Z1ZEhKcFpYTWdhVzRnZEdo
bGFYSWdaR2x5WldOMGIzSjVMbHh3WVhJTkNseHcNCllYSU5DbFJvWVc1cmN5eGNjR0Z5RFFwY2NH
RnlEUXBUZEdWMlpTQklZVzV1WVZ4d1lYSU5DbjA9DQotLS0tPV9OZXh0UGFydF9TVEpfODg3Mzk5
NjguMDk0NTQyNzE0LS0NCg0KoIILHjCCA6YwggKOoAMCAQICBD38y5IwDQYJKoZIhvcNAQEFBQAw
MTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQwHhcNMDMw
NzAyMTIxNzQ4WhcNMDQwMTAyMTI0NzQ4WjBZMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVz
dDEQMA4GA1UECxMHUiBhbmQgRDEmMA4GA1UEBRMHMTYxNjY3MTAUBgNVBAMTDVNoYXJvbiBCb2V5
ZW4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMQkJK7H7oW2RtKD+5d57k7BAXHy/aOs18nl
1jKPosZJQN9PhszRhnVCMZpyDkXq0PKG1v4tJbFrH5aCEFfROj3qMEwK+zxSVMLD4zpw5ciZNWwO
v65qxO9ifQUB8hV/LIBMCWPPvTPMGIRj3PkDrz8/EYy9BepH7unc3paVROFZAgMBAAGjggEgMIIB
HDALBgNVHQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwMzA3MDIxMjE3NDhagQ8yMDAzMTEwODA3NDc0
OFowJAYDVR0RBB0wG4EZc2hhcm9uLmJvZXllbkBlbnRydXN0LmNvbTBUBgNVHR8ETTBLMEmgR6BF
pEMwQTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQxDjAM
BgNVBAMTBUNSTDI1MB8GA1UdIwQYMBaAFPPwLCjmOac0GauakaimZkCSnOJxMB0GA1UdDgQWBBQ0
YnNZwTnlrV/mljLzDrF5k9BtcDAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgSw
MA0GCSqGSIb3DQEBBQUAA4IBAQBCGAJqHsgrxDyh90ing3LNDc3DQmbXn1TtcwHrHZDAeRXl+J/w
yMwkLVNeHJfRawgOy59UpEcIfawhdoUFn10XDU/fXY+azaJvNuK6YE6EEk8eH0xbRYpPkBBzrw/g
r+wp0sGmJGPySjbuqX4dOqJ/fnKpdTe/ZgvguctukfsWBP+X2DREJ2uC2/fB6uQwq8/1sKX2BHsL
MEeq/epfdzGRli0nN4lpSUTDpnMUCWAnMEYvj08nmtsQNaIMS9v9d1ok9ShV2MM59my+jlIE/qEI
yaHF9wPSZfUc2bjEty2+Wvuy6ttXYVdFCjeUNNaMcgInd6Clh269YsC8ivNH6sMJMIIDdzCCAl+g
AwIBAgIEPfzFLzANBgkqhkiG9w0BAQUFADAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVz
dDEQMA4GA1UECxMHUiBhbmQgRDAeFw0wMzA1MTIxMjA5MzBaFw0wMzExMTIxMjM5MzBaMFkxCzAJ
BgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMSYwDgYDVQQFEwcx
NjE2NjcxMBQGA1UEAxMNU2hhcm9uIEJvZXllbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
o6Fl6ltnYS/22/pvoIr8lO9eRkvdCinBx4tgVO+QRZF90u+QTtz4Brv9qf4I8FMTb8KSWQnjv4Dg
0gwjZnxZ+lxguVFFGrJrSDyOMCYPsKIGaz8JPrUvlQqfB/8Yu+1/4koVrHCxD4qI26vFF8D9mPGM
jQVQp1HoN/XEzDS+zGcCAwEAAaOB8jCB7zALBgNVHQ8EBAMCBSAwJAYDVR0RBB0wG4EZc2hhcm9u
LmJvZXllbkBlbnRydXN0LmNvbTBUBgNVHR8ETTBLMEmgR6BFpEMwQTELMAkGA1UEBhMCQ0ExEDAO
BgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQxDjAMBgNVBAMTBUNSTDI1MB8GA1UdIwQY
MBaAFPPwLCjmOac0GauakaimZkCSnOJxMB0GA1UdDgQWBBTf/D6k/mHuAALWEVNvhucj5Cx0xDAJ
BgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgSwMA0GCSqGSIb3DQEBBQUAA4IBAQBX
XhNix13ybT60c+xhpIFCdTyqCqoa8IHzdtWdI6ltun2zxmEGYzMnfXM8cx9vr5dEmWehIIeUt12h
lLiOBfdVoakEBJ6LaoLOkveKyEVpPdR9aMvEIl5zdslQKnzCWlFNh4HII2EjGVnnG4PY72EJ++0z
wYu7PTMzTD4Hrta6wSnImddXdou6zjW1Rg/ipzzC7sZLNqVyhEkUdO6NY04oH3lAfvSazcFHCED1
DNEb5rXC8OT2i+KhSKxY04gFehD0d6gzoe40ZW5STfmnz3bvXk7ClE/TvmJMc6hkrQ9Az3snyeg0
Ybu+xiauNDtEqbngXdeYt+LJfxIBfMN4Ver6MIID9TCCAt2gAwIBAgIEMkiqIDANBgkqhkiG9w0B
AQUFADAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDAe
Fw0wMjA0MTcwMjIwMjZaFw0yMjA0MTcwMjUwMjZaMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdF
bnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
vIeIjfoD5D86sD8CehB+kVhYJTL+VuaUZiVijGevUTlnUAwy1WpOYVpFCa8VK116TJ+o99axN1jM
bsVBYfRzFk9SWl4iAH+PyJ1S6D5Yl593KjHPhBCfdD0v9KoPqXhCwRlkvupreNlFx3FFk2Uf5jG/
i9SCP925OXbz3wod2mdIu8ueNWgTmA2XAOBdHZg6HYKo50BWUIgtRwFvzbh1J57+gNdHxMYLZmvj
5saS1mDTSibkPH/AY+D+xAozRmyOYa4SY2HVfZSM2SP7MkuVtKp17pzhwicoWAGKXrKeDRWDYeZB
TJjHoNP/SXKdpSzY7rV8GPrfWFoogc4350VbowIDAQABo4IBEzCCAQ8wEQYJYIZIAYb4QgEBBAQD
AgAHMFMGA1UdHwRMMEowSKBGoESkQjBAMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQ
MA4GA1UECxMHUiBhbmQgRDENMAsGA1UEAxMEQ1JMMTArBgNVHRAEJDAigA8yMDAyMDQxNzAyMjAy
NlqBDzIwMjIwNDE3MDI1MDI2WjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qR
qKZmQJKc4nEwHQYDVR0OBBYEFPPwLCjmOac0GauakaimZkCSnOJxMAwGA1UdEwQFMAMBAf8wHQYJ
KoZIhvZ9B0EABBAwDhsIVjYuMDo0LjADAgSQMA0GCSqGSIb3DQEBBQUAA4IBAQCAPnm1Rpn5ya5k
BLFpckRtw+XuY/G5m6uQH9hVXgechp+i6/tXlYjQ8ccnJy1HcOmPS718LkG4drxBfrhjO9aTudv+
TNIMR9izay796hsBk7raBpYtxavOEjxb8jfp+EelztgcSZo737mYzcrr9pDjzJldsriCzPDU/N05
2R+RJ4Rs/0IiuWzIVH7y99S9O+rG14PjEKNQhA39gTwg9iMBtQoksDfKu09UCaFsE7aYUC8eE0wz
ki4G+Dl5RKE57MGaYAh+cccmyPR6Xw/gl8Yo3YGhOWz3qatAhbbplACm9LSmduMSLXQybke6cq5J
Ub8c9VMzi9cIiv6Hbf1/xObPMYICZTCCAmECAQEwOTAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMH
RW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRAIEPfzLkjAJBgUrDgMCGgUAoIIBgjAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA4MDcxMzQ1NDJaMCMGCSqGSIb3DQEJ
BDEWBBTkmTRdT/XLmnfLmRRnAupInArpQjCCASEGCSqGSIb3DQEJDzGCARIwggEOMAsGCWCGSAFl
AwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMA8GCSqGSIb2fQdCCgICAIAwDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCysGAQQBgTwHAQECMA4GCSqGSIb2fQdCCgIBKDANBggqhkiG
9w0DAgIBKDAHBgUrDgMCBzAHBgUrDgMCGjAKBggqhkiG9w0CBTALBgkqhkiG9w0BAQEwCwYJKoZI
hvcNAQEHMAkGByqGSM44BAEwCQYHKoZIzj0CATALBgkqhkiG9w0BAQUwCwYJKoZIhvcNAQEEMAkG
ByqGSM44BAMwCQYHKoZIzj0EATAMBgoqhkiG9w0BCQ8BMA0GCSqGSIb3DQEBAQUABIGAfsZUoHUN
prl8MaOdfJijqbYExi274VF+XUsgrkkd+lwGisYKzgl4U5PXM9JfOVqpKIBtV1rkqvDKL78esfUG
Uts1YlimCU2bzRtm8MeB2r2+sz0yoQW5/FbarUM0oFZJYWCbY1bq4uLirXbQyyROUvGkE2ECCJif
2BBCxzBFVjw=


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h762BFqt058943 for <[e-mail]>; Tue, 5 Aug 2003 19:11:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h762BFjF058941 for ietf-pkix-bks; Tue, 5 Aug 2003 19:11:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from new_bruno (bruno.gric.com [216.231.202.145]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h762BDqt058917 for <[e-mail]>; Tue, 5 Aug 2003 19:11:13 -0700 (PDT) (envelope-from [e-mail])
Received: from salford.ac.uk (dialup-65.58.57.130.Dial1.Denver1.Level3.net [65.58.57.130]) by new_bruno (8.12.7/8.12.7) with ESMTP id h762A4TX026474; Tue, 5 Aug 2003 19:10:05 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 05 Aug 2003 14:23:22 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Leif Johansson <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
References: <[e-mail]> <[e-mail]> <p05210600bb4ad9ed31e9@[128.89.89.75]> <[e-mail]> <p05210605bb4aec47262b@[128.89.89.75]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------C9E835DA047B3DCA7167F013"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Leif Johansson wrote:

> The bottom line is that directores are widely deployed and pki is not.
> If pki is to have any
> chance to get integrated with the provisioning systems which *are*
> *already* deployed and
> used in enterprises today it must work with LDAP. No extensions. No
> add-ons.
> 

Leif

The main problem is that some LDAP vendors have not implemented basic
LDAP, but have subtracted some features from the LDAP standard that they
the vendors (but not their users) did not see a need for, such as
aliases, multi-valued RDNs, DIT structure rules and name forms, matching
rules etc. The PKIX group is wanting to use standard features from LDAP,
not extensions (and LDAP has defined plenty of those itself) or add ons.

regards

David

> >
> > Steve
> 
>     MVH leifj

-- 
*********************************************************

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 


*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------C9E835DA047B3DCA7167F013
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------C9E835DA047B3DCA7167F013--





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h762B6qt058913 for <[e-mail]>; Tue, 5 Aug 2003 19:11:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h762B6ZA058912 for ietf-pkix-bks; Tue, 5 Aug 2003 19:11:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from new_bruno (bruno.gric.com [216.231.202.145]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h762B0qt058895 for <[e-mail]>; Tue, 5 Aug 2003 19:11:00 -0700 (PDT) (envelope-from [e-mail])
Received: from salford.ac.uk (dialup-65.58.57.130.Dial1.Denver1.Level3.net [65.58.57.130]) by new_bruno (8.12.7/8.12.7) with ESMTP id h7629ZTX026427; Tue, 5 Aug 2003 19:09:45 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 05 Aug 2003 13:54:40 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "'PKIX'" <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
References: <001e01c357e3$61e70a70$[e-mail]>
Content-Type: multipart/mixed; boundary="------------CD18FAD4A3C5192A6AAB7708"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Steven Legg wrote:
> 
> David,
> 
> David Chadwick wrote:
> > Peter and I have resolved all the issues described at the PKIX meeting
> > today, apart from one, which is what should be the attribute
> > type to be
> > used to hold the X.509 DER encoded attribute. Should it be
> > the original
> > attribute type name e.g. userCertificate or a new attribute
> > whose schema
> > says it must be single valued. Comments please to the list to help us
> > resolve this final issue.
> 
> If the original attribute type name is used in the child entry then
> a client that uses the X.509 matching rules, or component matching rules,
> to match certificates in situ will get each certificate twice.

Steven

In this scenario, the LDAP server supports direct matching on X.509
attributes, and therefore does not need to store the child entries.
Therefore only one attribute will be there to be retrieved. The child
entries, and associated attribute extraction mechanism, has only been
introduced because LDAP servers and clients dont support direct matching
on X.509 attributes. If they had, then attribute extraction would never
have been needed. As it is, only one attribute (in the child entry) will
be retrieved by today's LDAP clients.

I do however agree that there will be a migration issue, if and when
some LDAP clients and servers support the direct matching, whilst others
dont. The direct matching clients will receive two entries, with
different RDNs, containing the same attribute. But this is not a real
problem is it? They can be configured to ignore the child entries since
these DNs wont match the DNs in the certificates. How long the problem
will persist will depend upon how quickly implementors move from the
extraction mechanism to the direct matching mechanism.

> Once in a
> subject's entry and once in a child entry of the subject. If a new
> attribute type is used then the child entries will not normally be seen
> by clients directly matching on certificates.
> 

The reason I dont want to use a new attribute type, is that thousands
(if not millions) of clients are already using the currently defined
attribute types, and I dont want to have to make them change
unnecessarily.

> Clients not using direct matching have to be configured to search on
> the extracted attributes. Configuring them to also ask for the new
> attribute type shouldn't be a serious impediment.
> 

I am not in a position to state whether it will or will not be a serious
impediment to PKI clients to change the names of the attributes that
they are using today. I suggest it could be a serious impediment to
some. It would be nice to hear from PKI client vendors and users about
this.

regards


David.

> Regards,
> Steven

-
--------------CD18FAD4A3C5192A6AAB7708
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------CD18FAD4A3C5192A6AAB7708--





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h762B6qt058914 for <[e-mail]>; Tue, 5 Aug 2003 19:11:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h762B6Bp058911 for ietf-pkix-bks; Tue, 5 Aug 2003 19:11:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from new_bruno (bruno.gric.com [216.231.202.145]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h762B5qt058897 for <[e-mail]>; Tue, 5 Aug 2003 19:11:05 -0700 (PDT) (envelope-from [e-mail])
Received: from salford.ac.uk (dialup-65.58.57.130.Dial1.Denver1.Level3.net [65.58.57.130]) by new_bruno (8.12.7/8.12.7) with ESMTP id h7629xTX026430; Tue, 5 Aug 2003 19:10:00 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 05 Aug 2003 13:56:16 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "'PKIX'" <[e-mail]>
Subject: Re: LDAPv3 Profile Issue
References: <002001c357ea$f60592b0$[e-mail]>
Content-Type: multipart/mixed; boundary="------------86E8B62C23DDDBF0585A6FCE"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------86E8B62C23DDDBF0585A6FCE
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Steven

thanks. I can now make the appropriate changes to the profile

David

Steven Legg wrote:
> 
> David,
> 
> David Chadwick wrote:
> > Colleagues
> >
> > at the Vienna meeting I stated that the only outstanding
> > issue with the
> > LDAPv3 profile was the use of multi-valued RDNs. However,
> > there is also
> > the use of the ;binary extension that still has to be addressed and
> > resolved (unfortunately), since the profile needs to state what PKI
> > clients should do with ;binary.
> 
> I thought this was already resolved. Tim Polk previously proposed the
> following to the list:
> 
>   (1) Upon review of the PKIX-LDAP “survey” we see a critical mass of PKI
> clients
>   and LDAP servers that achieve interoperability using LDAPv3 with the
> ;binary
>   option.  As these clients appear to be in the majority, we believe the
> best
>   approach is to maintain this option for the transfer of X.509 certificates
> and
>   CRLs.  Since this is the behavior documented in RFCs 2251, 2252, and 2256
> (as
>   well as the overarching 3377) this will require the least changes to the
> LDAPv3
>   specifications as well.
> 
>   (4) The lack of a defined LDAP-specific encoding for Certificate,
> Certificate
>   List and Certificate Pair syntaxes is a problem, as a small percentage of
>   implementations transfer these attributes without the ;binary option.
> Rather
>   than be silent, we suggest that the PKIX syntax and schema document state
> the
>   LDAP-specific encoding used in transfer without the ;binary option but
>   deprecate its use.  This LDAP-specific encoding has the same transfer
>   representation as when the attribute is transferred with the ;binary
> option.
> 
> As I recall there was no serious dissent. Consensus seems to have been
> achieved.
> I wrote draft-legg-ldap-binary-00.txt assuming this was the case.
> 
> Regards,
> Steven
> 
> >
> > The ;binary issue is holding up the final calls on the LDAPv3 profile,
> > and the LDAP PKI and PMI schema documents (from Steven Legg
> > and myself).
> > Fortunately it does not affect the LDAP attribute extraction schema
> > profiles that are due to be published as Informational RFCs, but
> > nevertheless we do need closure on the ;binary issue as soon
> > as possible
> >
> > regards
> >
> > David
> >
> > --
> > *********************************************************
> >
> > Leaders of the world's richest nations meet in Cancun on
> > September 10th
> > 2003. Oxfam is presenting them with a petition to make trade fair. Be
> > sure your voice is heard. Sign the 'Big Noise' petition to make trade
> > fair at:
> >
> > http://www.maketradefair.com/go/join/?p=omf1
> >
> >
> > *****************************************************************
> >
> > David W. Chadwick, BSc PhD
> > Professor of Information Systems Security
> > IS Institute, University of Salford, Salford M5 4WT
> > Tel: [phone]  Fax [phone]
> > Mobile: [phone]
> > Email: [e-mail]
> > Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> > Research Web site: http://sec.isi.salford.ac.uk
> > Seminars: http://www.salford.ac.uk/its024/seminars.htm
> > Entrust key validation string: MLJ9-DU5T-HV8J
> > PGP Key ID is 0xBC238DE5
> >
> > *****************************************************************

-- 
*********************************************************

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 


*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------86E8B62C23DDDBF0585A6FCE
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------86E8B62C23DDDBF0585A6FCE--





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75JOAqt030229 for <[e-mail]>; Tue, 5 Aug 2003 12:24:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75JOAxx030228 for ietf-pkix-bks; Tue, 5 Aug 2003 12:24:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75JO8qt030221 for <[e-mail]>; Tue, 5 Aug 2003 12:24:08 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h75JO5gn016466; Tue, 5 Aug 2003 12:24:05 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h75JO4s09772; Tue, 5 Aug 2003 15:24:04 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 05 Aug 2003 15:20:34 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX List <[e-mail]>, [e-mail]
Subject: PKIX LDAPv3 schema: component matching or separate entries
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA8B46CA38210A350F106092D"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

The draft minutes from the IETF 57 PKIX WG meeting say:

> LDAP Documents: - David Chadwick (Univ of Salford) & Peter Gietz
>                (DAASI)
> The WG has a suite of LDAP-PKIX drafts forming a comprehensive
> solution for LDAP based PKI information distribution.

I believe that the PK certificate schema is described in
draft-klasen-ldap-x509certificate-schema-03.txt.

That document (and the CRL and AC schemas) proposes a
change from storing certificates in the multi-valued
userCertificate and cACertificate attributes of an
entity's directory entry to storing certificates as
separate directory entries, subordinate to the entity's
directory entry. Values may then be extracted from
certificate fields and placed in attributes on the
certificate's directory entry so that it's easier to
search for certificates and retrieve only those you want.

At IETF 56, there was a discussion about whether to make
this change or stick with the current schema and use
component matching to solve the problem. As noted in the
meeting minutes, a straw poll favored component matching
but it was agreed to take this discussion to the mailing
list. I haven't seen any discussion on the mailing list,
but now it seems that the matter has been decided in favor
of the modified schema.

Did I miss something? Was this discussed and agreed to on
the mailing list? If not, it should be discussed here.

I would like to hear from customers who are using the old
schema as to whether they will be happy moving to the new
schema. I'm concerned that they may be reluctant to double
or triple the number of entries in their directory.

Thanks,

Steve Hanna
--------------msA8B46CA38210A350F106092D
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
CQUxDxcNMDMwODA1MTkyMDM0WjAjBgkqhkiG9w0BCQQxFgQUrfqxe5CzYfX+T448xNeKpFPn
5oswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB7EzNB
XGagVQqHlXMmK2NbFRNvZrLpjj03Rqer9xbn3jkRy2pB7qbIeU7b9bN1Zv0P/TyACzlkhu+2
1hM2WRbuoD6VUaj+HnSokemv6YaZMk16HTdqkN5WBaWSIi7OvNAwwLLe1QYH5VSehUzR+9ZD
cym4+lBilD+YS+e9qgiTWA==
--------------msA8B46CA38210A350F106092D--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75EFVqt012872 for <[e-mail]>; Tue, 5 Aug 2003 07:15:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75EFVk5012871 for ietf-pkix-bks; Tue, 5 Aug 2003 07:15:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75EFUqt012865 for <[e-mail]>; Tue, 5 Aug 2003 07:15:30 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12788; Tue, 5 Aug 2003 10:15:27 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pr-tsa-05.txt
Date: Tue, 05 Aug 2003 10:15:27 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Policy Requirements for Time-Stamping Authorities
	Author(s)	: D. Pinkas, N. Pope, J. Ross
	Filename	: draft-ietf-pkix-pr-tsa-05.txt
	Pages		: 40
	Date		: 2003-8-5
	
This document defines requirements for a baseline time-stamp policy 
for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, 
supported by public key certificates, with an accuracy of one 
second or better. A TSA may define its own policy which enhances 
the policy defined in the current document. Such a policy shall 
incorporate or further constrain the requirements identified in the 
current document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-05.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-pr-tsa-05.txt".

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pr-tsa-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pr-tsa-05.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h759owqt090942 for <[e-mail]>; Tue, 5 Aug 2003 02:50:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h759ow60090940 for ietf-pkix-bks; Tue, 5 Aug 2003 02:50:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h759ovqt090933 for <[e-mail]>; Tue, 5 Aug 2003 02:50:57 -0700 (PDT) (envelope-from [e-mail])
Received: from arport (t7o913p27.telia.com [213.64.26.27]) by smtp5.hy.skanova.net (8.12.9/8.12.9) with SMTP id h759oieV020212; Tue, 5 Aug 2003 11:50:45 +0200 (CEST)
Message-ID: <009d01c35b36$f3beb870$1b1a40d5@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Date: Tue, 5 Aug 2003 11:49:57 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Although I generally agree with Denis' analysis, I see some problems
with the deployment of Warranty Extensions occurring already at the
conceptual level:

If we take widely used transaction services like on-line banks, eBay
etc., they supply their end-users (customers) with some kind of
"Client Security Solution" and "End-user Agreements", that users
have to accept before getting access to the service(s).

Such End-user Agreements typically describe transaction limits,
warranties, mutual responsibilities etc.

Q: What would be the benefit for such a service to move (or duplicate)
parts of the "End-user Agreements" down to the "Client Security
Solution", in the [rare] case the latter is based on X.509 certificates?

/anders

----- Original Message ----- 
From: "Denis Pinkas" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, July 29, 2003 12:37
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."

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."

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.

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".

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."

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).

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.

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.


Denis



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7500eqt048215 for <[e-mail]>; Mon, 4 Aug 2003 17:00:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7500eVE048214 for ietf-pkix-bks; Mon, 4 Aug 2003 17:00:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7500bqt048188 for <[e-mail]>; Mon, 4 Aug 2003 17:00:38 -0700 (PDT) (envelope-from [e-mail])
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id <B000122b7c>; Tue, 05 Aug 2003 09:55:56 +1000
Received: (qmail 18282 invoked from network); 4 Aug 2003 23:55:28 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 4 Aug 2003 23:55:28 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'Michael Str der'" <[e-mail]>
Cc: "'PKIX'" <[e-mail]>
Subject: RE: Issues in LDAP schema IDs
Date: Tue, 5 Aug 2003 10:00:23 +1000
Message-ID: <002a01c35ae4$92414420$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

Michael Str der wrote:
> Steven Legg wrote:
> > 
> > If the original attribute type name is used in the child entry then
> > a client that uses the X.509 matching rules, or component 
> matching rules,
> > to match certificates in situ will get each certificate 
> twice. Once in a
> > subject's entry and once in a child entry of the subject.
> 
> Steven, I see your point. But doesn't that depend on the 
> syntax used for the 
> attribute?

Huh? The old and new attribute types would have the same syntax
(i.e. Certificate).

Regards,
Steven


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74I7uqt021272 for <[e-mail]>; Mon, 4 Aug 2003 11:07:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74I7ujh021271 for ietf-pkix-bks; Mon, 4 Aug 2003 11:07:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74I7sqt021266 for <[e-mail]>; Mon, 4 Aug 2003 11:07:55 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Aug 2003 11:07:51 -0700
Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 04 Aug 2003 11:07:49 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Aug 2003 11:07:51 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Aug 2003 11:07:55 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Aug 2003 11:07:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
Date: Mon, 4 Aug 2003 11:07:48 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-deacon-xkms-aia-00.txt
Thread-Index: AcNaokhhkG6vjkr1SV6+1Wikr/gyigADepYw
From: "Ryan M. Hurst" <[e-mail]>
To: "Deacon, Alex" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 04 Aug 2003 18:07:39.0261 (UTC) FILETIME=[4A887AD0:01C35AB3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h74I7tqt021267
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alex - Glad to see some one has put together a story for how this can be
represented in the X.509 world. I have a couple comments/questions
though,

   1. XKMS supports several different services (key information and key
      Registration) and implementations will likely only support a
profile
      of each.
      
	Should we assume the AIA only points to a XKMS Key Information
	service? If so should the OID be labeled as such?

      Should there be a PKIX profile of what a server supports when this
      OID is present in the AIA? For example what forms of key
	Identification are supported, I assume if it's being referred to
in a
      X.509 certificate it would minimally support the X.509 key
	identification form. What about the types of information that is
	available?

   2. XKMS may used in a variety of protocols, shouldn't the draft
indicate which transport that should be assumed in PKIX environments? 

	Is it assumed that this is just a post of a XKMS request, if so
is
	There a need for an application mime-type? Is it assumed it will
be
	Wrapped in a SOAP envelop and be routed based on that?

   3. Shouldn't there be a documented delegated trust model, ala OCSP
for
	XKMS Key Info? Maybe we need a XKMS Key Information EKU and the
same
      1 level rule set used in OCSP could be applied. This is important
for
	clients that are base relying parties and are not knowledgeable
enough
	to operate their own or explicitly choose a third-party to do
this for
	them.

I have to admit I am not a XKMS pro, so some of these questions may
sound out of place but they were the first ones to come to mind when I
saw this.

Ryan M. Hurst



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Monday, August 04, 2003 7:14 AM
Cc: [e-mail]
Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: AIA Access Method for XKMS Services
	Author(s)	: A. Deacon
	Filename	: draft-deacon-xkms-aia-00.txt
	Pages		: 5
	Date		: 2003-8-4
	
Authority Information Access extension that is used to indicate how
to access CA information and services for the issuer of the
certificate in which this extension appears.  This document defines
an access method identifier that indicates the location of XKMS
[XKMS] services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-deacon-xkms-aia-00.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-deacon-xkms-aia-00.txt".

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-deacon-xkms-aia-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Gm0qt016767 for <[e-mail]>; Mon, 4 Aug 2003 09:48:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74Gm0MO016766 for ietf-pkix-bks; Mon, 4 Aug 2003 09:48:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74Glwqt016759 for <[e-mail]>; Mon, 4 Aug 2003 09:47:58 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA04973 for <[e-mail]>; Mon, 4 Aug 2003 18:47:58 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 4 Aug 2003 18:47:58 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h74Glvm01909 for [e-mail]; Mon, 4 Aug 2003 18:47:57 +0200 (MEST)
Date: Mon, 4 Aug 2003 18:47:57 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: first comments for SCVP 12
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a first list of comments regarding SCVP draft 12. This
does not take into account various comments from other people
so some text may be redundant.

Chapter 3:

I am not convinced that it is a good idea to copy definitions from CMS.

There are some comments as annotations which should be explained
in text, e;g; why is there only one signerInfo present? 
I don't see why there couldn't be several signatures or
countersignatures (for example in relaying). 

  " There are two forms of SCVP request: unsigned and signed.  A signed 
   request can be used to authenticate the client to the server. "

This seems to require a modification concerning the addition of
authenticated data. 

3.5 reqExtensions 
 
 " An SCVP server MUST reject the query if it encounters a 
   critical extension it does not recognize;  "

which error code should be used? 22? 

4: 

Same remark as for chapter 3 about copying the syntax.

The response can be eieyther signedData or authenticated? what
if a client implementation only support one option, and a 
server only the other?

it is very unclear why the signedData have all the MUSTs about
ess signing certificate etc. 

  " The SCVP server MUST include its own certificate in the certificates 
   field within SignedData."

Why this?  Well, the requirements doc says:

  "The DPV server's certificate MUST authenticate the DPV server."

How is this supposed to be done in SCVP? T
The current text says that the server MUST return its
certificate, the client matches this against what? It may be difficult
distngusih from any end entity providing SCVP responses. Configuring 
the client requires in this case at least
an identity + some CA cert or a separate tree...
 
It seems useful to me to have a special extendedKeyusage (id-kp) such
as for OCSP, TSA etc.  and also to follow at least the trust models 
of OCSP.



I propose to rewrite the sections along the following lines:

- first, the payload definition

- then sections about security envelopes addressing different
  requirements, in particular:
  - the client is the only RP.
  - the client will use the response to show it another RP
  (Shouldn't this be part of a policy or a wantback? i.e. 'signature required')?
  

4.3: is it necessary to have status codes which have non consecutive
     numbers. This seems to me a left over from a textual version
     where somehow like in SMTP the code is actaully a combination
     of three codes or else. 

     There are several codes refering to signedData signature
     problems but none about authenticated data?

     40 shouldn't this say: 'The server detected a loop during relaying'?

Why this?

     ReplyWantBack::= SEQUENCE { 
       wb                         OBJECT IDENTIFIER, 
       value                      OCTET STRING } 

and not 
     ReplyWantBack::= SEQUENCE { 
       wb                         OBJECT IDENTIFIER, 
       value                      ANY DEFINED BY wb } 


What is the intention of using [1] and [2] tags? 

     CertReply ::= SEQUENCE { 
       cert                       CertReference, 
       replyStatus                ReplyStatus, 
       replyValTime               GeneralizedTime, 
       replyChecks                ReplyChecks, 
       replyWantBacks             ReplyWantBacks, 
       valPolicy                  ValidationPolicy, 
       nextUpdate             [1] GeneralizedTime OPTIONAL, 
       certReplyExtensions    [2] Extensions OPTIONAL } 

(There are some other places in the syntax. It seems that tags are
 systematically used for optional tags even if not required).

4.4
  " When using connectionless protocols, the requestRef item allows the 
   client to associate a response with a request. "

replace by: 

   The requestRef item allows the client and other relying parties 
   to associate a response with a request.


4.5: 

I think that someone has misunderstood the requirement. well, it
may not be clear in the requirements doc, since after spending
several months of fights ... Anyway:

  " When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response."

The (at least my) idea was to have a "GeneralNames" since this is
waht is used everywhere else in PKIX for identifiers.    

For relaying the identifiers must be globally unique. creating a new
octet string based type may a new nice way to get of DNs or other
naming contexts, but saying

   "The OPTIONAL requestor item is used to identify the requestor.  The 
   value is only of local significance to the requestor. "

is asking for problems because two servers may choose the same id, or
worse, one chooses a prefix of another followed by a a zero octet.  
 
4.6 

Similar here. 

In fact, the requirement is that both the request and the response
have a requestor and a responder field.  

The requestor in the request indicates who is asking, or, in the
response, to whom the reqponse is provided.

The responder in the request indicates who is th intended id of
the provider, and in the response, who actually provided the
response. 

The impact to chapter 7 are obvious:

- A server MUST add HIS identity in the requestor field.*
- A server MUST perform inbound loop detection, i.e., detect
  if the requestor field already cntains its own identity.
- A server MAY perfom outbound relay checks, in the relayed server 
  identity is known. 

- A relaying server must add his identity in the responder field 
  of the response.

4.7.8

Since the protocol defines so many new types, I wonder why it is
necessary to reuse the Extension type here since the critical bit
needs to be set to false anyway. And: The syntax already defines
some policies using "any defined by" or even SEQUENCE {oid, string)
why not simply using the same. 

4.8

I am not yet sure whether it is really necessary but I propose that 
the Nonce returned must have a prefix that corresponds to the request
nonce.

Relaying: A server that is relaying one half of the request to one
server, and another to another, how does the server include the
responses from the two services, allowing another relying party to
validate them? How are DPV responses from other servers included in
a response?


Well, so far, it is getting too hot here to continue....
Peter


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74EERqt005715 for <[e-mail]>; Mon, 4 Aug 2003 07:14:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74EERaj005714 for ietf-pkix-bks; Mon, 4 Aug 2003 07:14:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74EEPqt005705 for <[e-mail]>; Mon, 4 Aug 2003 07:14:26 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27357; Mon, 4 Aug 2003 10:14:22 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt
Date: Mon, 04 Aug 2003 10:14:21 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: AIA Access Method for XKMS Services
	Author(s)	: A. Deacon
	Filename	: draft-deacon-xkms-aia-00.txt
	Pages		: 5
	Date		: 2003-8-4
	
Authority Information Access extension that is used to indicate how
to access CA information and services for the issuer of the
certificate in which this extension appears.  This document defines
an access method identifier that indicates the location of XKMS
[XKMS] services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-deacon-xkms-aia-00.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-deacon-xkms-aia-00.txt".

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-deacon-xkms-aia-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-deacon-xkms-aia-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74A0gqt083800 for <[e-mail]>; Mon, 4 Aug 2003 03:00:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74A0g1J083799 for ietf-pkix-bks; Mon, 4 Aug 2003 03:00:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [212.157.154.44]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74A0dqt083793 for <[e-mail]>; Mon, 4 Aug 2003 03:00:40 -0700 (PDT) (envelope-from [e-mail])
Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 4 Aug 2003 12:00:39 +0200
Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 04 Aug 2003 12:00:39 +0200
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 4 Aug 2003 12:00:35 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on draft-ietf-pkix-sonof3039-01.txt
Date: Mon, 4 Aug 2003 11:00:34 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-sonof3039-01.txt
Thread-Index: AcNXALhhvdd758MUTCGy2Cje5uiypADbmuRg
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 04 Aug 2003 10:00:35.0661 (UTC) FILETIME=[3FE8FFD0:01C35A6F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h74A0eqt083795
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

Thank you very much for this review.

I will fix in the next version.

/Stefan

-----Original Message-----
From: Jim Schaad [mailto:[e-mail]] 
Sent: den 31 juli 2003 03:12
To: Stefan Santesson
Cc: [e-mail]
Subject: Comments on draft-ietf-pkix-sonof3039-01.txt

Stefan,

1.  Appendix A:  3280, unlike 2459 only has the 1988 ASN.1 syntax.  You
need to consider removing the 1993 syntax from you document.

2.  Appendix A.1: You need to issue and updated module of some type
refering to the ASN.1 module from RFC 3280.

ASN.1 Issues:

3.  Attribute is imported but never referenced.
4.  id-at-serialNumber is defined in RFC 3280 ASN.1 module
5.  id-at-pseudonym is defined in RFC 3280 ASN.1 module

The last two are noted only because you make the statement that you
define only those things not in RFC 3280.

Jim






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h72Ck5qt003131 for <[e-mail]>; Sat, 2 Aug 2003 05:46:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h72Ck5oX003130 for ietf-pkix-bks; Sat, 2 Aug 2003 05:46:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h72Ck1qt003102 for <[e-mail]>; Sat, 2 Aug 2003 05:46:04 -0700 (PDT) (envelope-from [e-mail])
Received: from cbuwdostalek2 (gprsh1.isp.t-mobile.cz [62.141.24.1]) by click.cz (8.12.9/8.12.9) with ESMTP id h72CjXuf014716 for <[e-mail]>; Sat, 2 Aug 2003 14:45:36 +0200 (MET DST)
From: <[e-mail]>
To: <[e-mail]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Sat, 2 Aug 2003 14:43:33 +0200
Message-ID: <006c01c358f3$b633c850$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C35904.79BC9850"
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.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_006D_01C35904.79BC9850
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis,

You are right. You wrote: "PKUP could be a useful extension ...".

But in RFC-3280 is: "This extension SHOULD NOT be used within the
Internet PKI." (section 4.2.1.4). It is problem.

 

Libor

 

> -----Original Message-----

> From: Denis Pinkas [mailto:[e-mail]]

> Sent: Wednesday, July 30, 2003 11:07 AM

> To: [e-mail]

> Cc: [e-mail]

> Subject: Re: Why is privateKeyUsagePeriod deprecated?

> 

> Libor,

> 

> (...)

> 

> Yes. PKUP could be a useful extension for self-signed certificates,
*if*

> the

> Subject Information Access extension defined in section 4.2.2.2 from
RFC

> 3280 is also used. In that case, the id-ad-caRepository OID SHALL be
used

> to

> indicate in which repository the CA publishes its certificates.

> 

> Denis

> 

> > From my point of view, PKUP could be an useful extention of CA
certs.

> > CA must issue its new cert long time before expiration of its own

> > certificate (this period is min of max of the time validity of
issued EE

> > certs).

> 

> > It means: After issuing new CA cert (new-new) the old CA cert
(old-old)

> > is still valid but an appropriate old private key of the CA is not
used

> > henceforth. This private key should be authoritative erased when

> > the new certificate CA is issued. Lifetime of private key is shorter

> > than the validity period of the certificate. This lifetime of
private

>  > key could be indicated in PKUP.

> 

> > Today, the lifetime of private key is indicated in the certificate

> > policy (CP). Unfortunately it is not possible to start procedure

> > for downloading new CA certs (old-new, new-new and new-old)

> > automatically because the certificate policy (CP) is a nonstructured

>  > text. In practice, the lifetime of CA private key is not even

>  > published in CP yet. It is published in CPS (RFC-2527) which is not

>  > in case of the majority of CAs public. Therefore it might by useful

>  > to indicate this information in the PKUP.

> 

> > Libor Dostalek

> 

 


------=_NextPart_000_006D_01C35904.79BC9850
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 69.6pt 70.85pt 69.6pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DCS link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Denis,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>You are right. You wrote: &quot;PKUP could be =
a useful
extension ...&quot;.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>But in RFC-3280 is: &quot;This extension =
SHOULD NOT be
used within the Internet PKI.&quot; (section 4.2.1.4). It is =
problem.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>Libor</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; -----Original =
Message-----</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; From: Denis Pinkas =
[mailto:[e-mail]]</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; Sent: </span></font><span
 lang=3DEN-US>Wednesday, July 30, 2003</span><span lang=3DEN-US> =
</span><span lang=3DEN-US>11:07 AM</span></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; To: [e-mail]</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; Cc: [e-mail]</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; Subject: Re: Why is =
privateKeyUsagePeriod
deprecated?</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; Libor,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; (...)</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; Yes. PKUP could be a useful extension =
for
self-signed certificates, *if*</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; the</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; Subject Information Access extension =
defined in
section 4.2.2.2 from RFC</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; 3280 is also used. In that case, the =
id-ad-caRepository
OID SHALL be used</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; to</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; indicate in which repository the CA =
publishes its
certificates.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; Denis</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; From my point of view, PKUP could =
be an
useful extention of CA certs.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; CA must issue its new cert long =
time before
expiration of its own</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; certificate (this period is min of =
max of
the time validity of issued EE</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; certs).</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; It means: After issuing new CA cert
(new-new) the old CA cert (old-old)</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; is still valid but an appropriate =
old
private key of the CA is not used</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; henceforth. This private key should =
be
authoritative erased when</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; the new certificate CA is issued. =
Lifetime
of private key is shorter</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; than the validity period of the =
certificate.
This lifetime of private</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &nbsp;&gt; key could be indicated in =
PKUP.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; Today, the lifetime of private key =
is
indicated in the certificate</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; policy (CP). Unfortunately it is =
not
possible to start procedure</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; for downloading new CA certs =
(old-new,
new-new and new-old)</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; automatically because the =
certificate policy
(CP) is a nonstructured</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &nbsp;&gt; text. In practice, the =
lifetime of CA
private key is not even</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &nbsp;&gt; published in CP yet. It is =
published
in CPS (RFC-2527) which is not</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &nbsp;&gt; in case of the majority of =
CAs public.
Therefore it might by useful</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &nbsp;&gt; to indicate this information =
in the
PKUP.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; &gt; Libor Dostalek</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&gt; </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_006D_01C35904.79BC9850--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71FsDqt007744 for <[e-mail]>; Fri, 1 Aug 2003 08:54:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h71FsDgj007743 for ietf-pkix-bks; Fri, 1 Aug 2003 08:54:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71FsBqt007727 for <[e-mail]>; Fri, 1 Aug 2003 08:54:11 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V71F2EMR06166 for <[e-mail]>; Fri, 01 Aug 2003 11:50:22 -0400
Received: (qmail 12322 invoked by uid 64014); 1 Aug 2003 15:47:28 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.276507 secs); 01 Aug 2003 15:47:28 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by 10.4.61.249 with SMTP; 1 Aug 2003 15:47:27 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <PLMFKXF8>; Fri, 1 Aug 2003 11:54:03 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "pkix (E-mail)" <[e-mail]>
Subject: Multi-valued RDNs
Date: Fri, 1 Aug 2003 11:54:03 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35845.213ADF80"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C35845.213ADF80
Content-Type: text/plain;
	charset="iso-8859-1"

I just want to add a little bit of what my experience with reality is. We do
have many customers who have deployed PKI with multi-valued RDNs as the
final RDN in their end-entity certificates. I'm not aware of any that have
multi-valued RDNs in the names of CAs or CRLs. The multi-valued RDNs form an
integral part of many large deployments. These naming schemes are generally
a result of the customer wanting a name scheme that is common to their
certificates and their DIT, that unambiguously identified the user with
attributes that are used in the non-electronic world, while not wanting to
necessitate a DIT that is unneccessarily deep (usually for performance
reasons). Multi-valued RDNs provide a solution for them.  I do NOT want to
debate with folks on this list whether or not they believe those are the
best name schemes. Rather I want to simply state that in my experience, many
such environments do exist. Therefore, assuming reality is important to the
discussion,  this is an important element of the standard that should be
retained.

Cheers,
Sharon



LDPsSharon Boeyen
Principal, Advanced Security
Tel: [phone]
Fax: [phone] 
Entrust
Securing Digital Identities
& Information
http://www.entrust.com



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Multi-valued RDNs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I just want to add a little bit of =
what my experience with reality is. We do have many customers who have =
deployed PKI with multi-valued RDNs as the final RDN in their =
end-entity certificates. I'm not aware of any that have multi-valued =
RDNs in the names of CAs or CRLs. The multi-valued RDNs form an =
integral part of many large deployments. These naming schemes are =
generally a result of the customer wanting a name scheme that is common =
to their certificates and their DIT, that unambiguously identified the =
user with attributes that are used in the non-electronic world, while =
not wanting to necessitate a DIT that is unneccessarily deep (usually =
for performance reasons). Multi-valued RDNs provide a solution for =
them.&nbsp; I do NOT want to debate with folks on this list whether or =
not they believe those are the best name schemes. Rather I want to =
simply state that in my experience, many such environments do exist. =
Therefore, assuming reality is important to the discussion,&nbsp; this =
is an important element of the standard that should be =
retained.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sharon</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">LDPs</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New">Sharon Boeyen</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Principal, Advanced =
Security</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel: [phone]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Fax: [phone] </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Entrust</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Securing Digital =
Identities</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&amp; Information</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"http://www.entrust.com" =
TARGET=3D"_blank">http://www.entrust.com</A></FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C35845.213ADF80--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71FYTqt007033 for <[e-mail]>; Fri, 1 Aug 2003 08:34:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h71FYT6N007032 for ietf-pkix-bks; Fri, 1 Aug 2003 08:34:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from cmailm2.svr.pol.co.uk (cmailm2.svr.pol.co.uk [195.92.193.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71FYSqt007027 for <[e-mail]>; Fri, 1 Aug 2003 08:34:28 -0700 (PDT) (envelope-from [e-mail])
Received: from modem-1050.leopard.dialup.pol.co.uk ([217.135.148.26] helo=PEDIGREE) by cmailm2.svr.pol.co.uk with smtp (Exim 4.14) id 19ibvD-0007UE-Ss; Fri, 01 Aug 2003 16:34:24 +0100
From: "Dean Adams" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
Subject: Closure of: Why is privateKeyUsagePeriod deprecated?
Date: Fri, 1 Aug 2003 16:34:21 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Tom,
	I agree with all that you say.  I suppose that given the IESG position as
reported by Steve, then any further discussion on this topic would perhaps
be fruitless.

	Dean


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Tom Gindin
> Sent: 01 August 2003 12:26
> To: Dean Adams
> Cc: [e-mail]
> Subject: RE: Why is privateKeyUsagePeriod deprecated?
>
>
>
>         Dean:
>
>         It doesn't seem that the IESG really wants us to define a
> protocol
> for this.  My assumption was that while a "FullHistoryCRL" in your sense
> is not normally maintained and expensive either to create or download,
> there is such a thing as a past CRL which would merely need to be
> archived.  Any client application doing historic verification and
> retrieving CRL's would need a lot of new code anyway, since no standard
> for that exists.  I think the date is a better filter for the
> retrieval of
> a past CRL than the certificate.
>         The X.509 standard does require that CA's supporting an
> NR service
> archive CRL's, presumably for historic verification if needed (see note 2
> of X.509v4 section 7.3 or of X.509v3 section 11.2).  However, there is no
> protocol or standard technique for retrieving those CRL's.
>         OCSP RP's may need to do archiving in any case for evidence
> preservation.  I don't see how a historic OCSP query would work
> except off
> a CRL.
>
>                 Tom Gindin
>
>
>
>
>
> "Dean Adams" <[e-mail]>
> 07/31/2003 06:42 AM
>
>
>         To:     Tom Gindin/Watson/IBM@IBMUS
>         cc:     <[e-mail]>
>         Subject:        RE: Why is privateKeyUsagePeriod deprecated?
>
>
>
> Tom,
>                  Apologies for my delayed response - unfortunately I am
> working on multiple
> PKI deployments and only have limited opportunity to keep up with these
> emails.
>
> I appreciate your comments, but I think that I didn't explain myself
> clearly
> enough.  The "FullHistory CRL" suggestion listed as being a (2) style of
> approach was meant to contain all certs that have ever been revoked under
> a
> particular CA cert.  Therefore, no parameters would be necessary - you
> would
> be guaranteed to be able to establish if a particular client cert had ever
> been revoked, and when.  Not sure if this suggestion is a winner, since
> for
> very large and long term deployments, this CRL could be very large.  On
> the
> other hand, only RPs that are verifying signatures on docs or transactions
> after the cert has expired, would need to pull this down.  It would never
> be
> needed for authentication activities, or for the period when the cert is
> still valid.
>
> Your discussion of parameters being supplied is probably a better approach
> from a network performance perpective, since it provides a way for the RP
> client application to be able to specify more tightly what revocation
> information it is interested in, by perhaps supplying a date as a
> parameter
> (as you suggest), or by presenting the client cert being verified and
> letting the CA determine (by whatever means it decides to use) if the cert
> had been revoked and when - then communicating that info back to the RP.
> This is the tyoe of approach I meant to hint at in the list item (1).
>
> Unfortunately, any work in this area would seem to require a change to
> client applications.
>
> If we want PKI to be able to service the signing and long term
> verification
> of documents and transactions, we need some way of allowing an RP to be
> able
> to get certificate status information, for a long time after the
> certificate
> expired.  I cannot agree with Denis that it is the obligation of each RP
> to
> archive such material for possible future use.  This is not user friendly,
> and is in any case impractical for the vast majority of simple
> consumer-type
> users who may be required to verify signatures over an extended period and
> who (even if they did archive CRLs) may not be able to so if they somehow
> lose the archived CRL (unless we also wanted to impose disaster revovery
> requiremts on each simple consumer-type user).  Lets remeber that the I in
> PKI is infrastructure - make provide the services that people need to be
> able to carry on their normal lives without becoming computer wizards.
>
>                  Regards
>                  Dean
>
>
> >         Dean:
> >
> >         I don't see how a full history CRL location would work without a
> > parameter for the effective date.  FreshestCRL doesn't need such a
> > parameter.  If we assumed that we want an "archivedCRL" accessMethod in
> > AIA, how would the accessLocation represent the effective date
> parameter?
> > I assume that it's appropriate for such an accessMethod to use HTTP or
> > HTTPS.
> >         An example of the URL for the actual query (for about now) would
> > be:
> >         https://www.publicCA.com/archivedCRL?date=200307301530Z
> >         An RP actually using this feature would be able to construct the
> > query by substituting the effective time into the URL.  I also would ask
> > if we need variants of this for "last CRL not later than" and "first CRL
> > not before".
> >
> >                 Tom Gindin
> >
> >
> >
> >
> >
> > "Dean Adams" <[e-mail]>
> > Sent by: [e-mail]
> > 07/29/2003 04:37 PM
> >
> >
> >         To:     <[e-mail]>
> >         cc:
> >         Subject:        RE: Why is privateKeyUsagePeriod deprecated?
> >
> >
> >
> >
> > Russ,
> >                  Surely, merely finding some way to ensure that a CA
> > archives CRLs is not
> > enough.  Some way has to be provided to allow client applications to
> > discover where the appropriate CRL to be checked, can be found.
> >
> > Some possible options for consideration:
> > 1) the first CRL that was published after the
> >    expiry date of the client cert being checked
> > 2) the location of a fully maintained complete CRL
> >    containing all history with regard to revoked certs
> >    that were issued from a particular CA certificate
> >
> > I'm sure there are other options too, but in any case some means of
> > communicating this info to the client application needs to be defined.
> > Perhaps some certificate extension similar to "Freshest CRL" that
> instead
> > denotes "FullHistory CRL" would be appropriate?  That (or something in
> > Authority Info Access) might provide a solution for (2).  Not sure how
> you
> > might go about providing a solution for a (1) type of approach, without
> > getting overly complicated.
> >
> > Dean Adams
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Russ Housley
> > Sent: 29 July 2003 16:56
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: Why is privateKeyUsagePeriod deprecated?
> >
> >
> >
> > Peter:
> >
> > On one hand I agree, but on another I do not.
> >
> > I agree that signatures need to be validated after the certificate
> > expires.
> >
> > The algorithm in RFC 3280 allows the certificate to be validate with
> > respect to a date other than today.  The date that ought to be input
> > requires a trusted time that the signature was applied.  Of course, PKIX
> > has developed a protocol to provide such a time stamp.
> >
> > An archive of the revocation information is not routinely offered by
> > CAs.  How do we make that happen?
> >
> > Russ
> >
> > At 01:32 AM 7/23/2003 +1200, Peter Gutmann wrote:
> >
> > >Stephen Kent <[e-mail]> writes:
> > >
> > > >I was not an author for 2459 or 3280, but my feeling is that we do
> not
> > > >recommend use of PKUP for several reasons:
> > >
> > >But those are mostly just hypothetical objections.  At the moment we
> have
> > two
> > >inescapabable facts:
> > >
> > >1. CAs issue certs based on a 1-year billing cycle, and nothing anyone
> > says
> > >    will change that.  No CA will issue a cert with a 20-year lifetime,
> > unless
> > >    it's for its own CA certs.
> > >
> > >2. Users need to use certs to validate signatures at n times the
> > CA-ordained
> > >    lifetime.  In the abscence of any mechanism to do this, they are
> > ignoring
> > >    the cert expiry time.  In other words, out of necessity, they're
> > > making the
> > >    following change to RFC 3280:
> > >
> > >     The validity period for a certificate is the period of time from
> > > notBefore
> > >     through notAfter, inclusive.  When used with signing certificates,
> > >     implementations SHOULD NOT pay any attention to the notAfter date.
> > >
> > >Given that this isn't going to change, it would seem that some guidance
> > for
> > >users would be useful here.  Since neither (1) nor (2) can be altered,
> > what
> > >would be needed is a simple extension, found in signing certs,
> > containing
> > a
> > >date to which the cert can still be used for signature-checking beyond
> > the
> > >obvious notAfter value.  This could be written up as a short one-page
> > >application note, no more (well, a bit more once you add all the usual
> > >boilerplate and whatnot).
> > >
> > >Now CAs can still decide not to issue certs like that, but (a) they
> can't
> > >justify it by claiming it screws up their standard cert cycle because
> it
> > >doesn't affect validTo/validFrom, and (b) users at least have some
> > guidance
> > as
> > >to what to do, which is better than the current situation where all
> they
> > can
> > >do is ignore parts of the standard on an ad hoc basis.
> > >
> > >Peter.
> >
> >
> >
> >
> >
> >
>
>
>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71EQ9qt001654 for <[e-mail]>; Fri, 1 Aug 2003 07:26:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h71EQ9nV001653 for ietf-pkix-bks; Fri, 1 Aug 2003 07:26:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71EQ8qt001629 for <[e-mail]>; Fri, 1 Aug 2003 07:26:08 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h71EPuD9012213; Fri, 1 Aug 2003 10:25:56 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210600bb501fcc5896@[128.89.89.75]>
In-Reply-To: <00f201c357c7$dfc95d10$020aff0a@tsg1>
References: <p05210604bb4eed81d497@[128.89.89.75]> <00f201c357c7$dfc95d10$020aff0a@tsg1>
Date: Fri, 1 Aug 2003 10:23:07 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 17:56 -0700 7/31/03, todd glassey wrote:
>Stephen this is the fundamental failing of the IESG to not 'slap you silly'
>for this... But you nor any other WG Chair were empowered to make your WG a
>fiefdom, so it is not for you to say what is and is not a standard nor is it
>appropriate for you to make any value judgments as a WG chair as to what the
>IETF is all about. That is for its members to decide and as a member you get
>one and only one vote... and as a WG Chair you get NO votes.

As usual, you misunderstand.  The IETF is defined by its membership, 
and it empowers WG chairs, the IESG and the IAB to make value 
judgements. If the value judgements are seen to be inappropriate, 
there are appeal processes available to the parties who think they 
have been wronged.  This is true of other standards bodies as well. 
Your notion of how a standards body should operate is NOT accepted or 
practiced by any of standards bodies with which I am familiar, e.g., 
ANSI, ITU, ETSI, IEEE, ...  Because we don't formally vote on 
matters, WG chairs also are empowered to decide when WG consensus is 
achieved.  IESG members must agree on whether a given document from a 
WG is suitable as an Internet standard, which is most certainly a 
value judgement.

Standards bodies do not exist merely to generate documents; they 
exist to develop and approve documents as standards and that requires 
making choices about what to approve and what to reject. This has 
always been true, and it is true not only in the IT industry, but in 
standards bodies for construction, safety, electrical engineering, 
etc.  Why can't you understand this fundamental principle?

>WG Chairs are there (they exist) as facilitators to make sure that fair and
>open and the rest of the language about WG's and the IETF's standards
>process are implemented. Which is to say you as a WG Chair were the
>implementer of policy not its creator.

Wrong again. WG chairs are usually subject matter experts and as such 
participate in the development of the standards in their WGs.  In a 
number of instances they are even authors or co-authors of documents 
within the WGs they chair.

>Oh - as to the comment you made to me about veiled threats - I don't make
>them.
>
>Todd Glassey

Well, you have managed to fool a lot of folks in that regard, because 
that it precisely how all of your "if you keep behaving this way 
someone may sue you" comments are interpreted by many.  And, you have 
received feedback from others. not just me, saying precisely that. 
So, if your intent is not to be perceived that way, you should learn 
to rephrase yoor comments.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71DFIqt091991 for <[e-mail]>; Fri, 1 Aug 2003 06:15:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h71DFIAc091990 for ietf-pkix-bks; Fri, 1 Aug 2003 06:15:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (krl9-d9bb4edd.pool.mediaWays.net [217.187.78.221]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71DFGqt091981 for <[e-mail]>; Fri, 1 Aug 2003 06:15:16 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 74F9195851; Fri,  1 Aug 2003 15:15:00 +0200 (CEST)
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id B62FA2A38E; Fri,  1 Aug 2003 15:14:59 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 01 Aug 2003 15:14:59 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030626
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Cc: "'PKIX'" <[e-mail]>
Subject: Re: Issues in LDAP schema IDs
References: <001e01c357e3$61e70a70$[e-mail]>
In-Reply-To: <001e01c357e3$61e70a70$[e-mail]>
X-Enigmail-Version: 0.76.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steven Legg wrote:
> 
> If the original attribute type name is used in the child entry then
> a client that uses the X.509 matching rules, or component matching rules,
> to match certificates in situ will get each certificate twice. Once in a
> subject's entry and once in a child entry of the subject.

Steven, I see your point. But doesn't that depend on the syntax used for the 
attribute?

> Clients not using direct matching have to be configured to search on
> the extracted attributes. Configuring them to also ask for the new
> attribute type shouldn't be a serious impediment.

Unfortunately while most clients (e.g. MUA) allow to tweak an LDAP filter 
they won't allow you to configure the attribute from which to grab the cert.

Ciao, Michael.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71BQSqt083440 for <[e-mail]>; Fri, 1 Aug 2003 04:26:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h71BQS9p083439 for ietf-pkix-bks; Fri, 1 Aug 2003 04:26:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h71BQQqt083415 for <[e-mail]>; Fri, 1 Aug 2003 04:26:26 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h71BQKkh165272; Fri, 1 Aug 2003 07:26:20 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h71BQI77115738; Fri, 1 Aug 2003 07:26:19 -0400
To: "Dean Adams" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: RE: Why is privateKeyUsagePeriod deprecated?
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 1 Aug 2003 07:26:13 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.1 w/SPRs JHEG5JQ5CD, THTO5KLVS6, JHEG5HMLFK, JCHN5K5PG9|March 27, 2003) at 08/01/2003 07:26:19, Serialize complete at 08/01/2003 07:26:19
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Dean:

        It doesn't seem that the IESG really wants us to define a protocol 
for this.  My assumption was that while a "FullHistoryCRL" in your sense 
is not normally maintained and expensive either to create or download, 
there is such a thing as a past CRL which would merely need to be 
archived.  Any client application doing historic verification and 
retrieving CRL's would need a lot of new code anyway, since no standard 
for that exists.  I think the date is a better filter for the retrieval of 
a past CRL than the certificate.
        The X.509 standard does require that CA's supporting an NR service 
archive CRL's, presumably for historic verification if needed (see note 2 
of X.509v4 section 7.3 or of X.509v3 section 11.2).  However, there is no 
protocol or standard technique for retrieving those CRL's.
        OCSP RP's may need to do archiving in any case for evidence 
preservation.  I don't see how a historic OCSP query would work except off 
a CRL.

                Tom Gindin





"Dean Adams" <[e-mail]>
07/31/2003 06:42 AM

 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     <[e-mail]>
        Subject:        RE: Why is privateKeyUsagePeriod deprecated?



Tom,
                 Apologies for my delayed response - unfortunately I am 
working on multiple
PKI deployments and only have limited opportunity to keep up with these
emails.

I appreciate your comments, but I think that I didn't explain myself 
clearly
enough.  The "FullHistory CRL" suggestion listed as being a (2) style of
approach was meant to contain all certs that have ever been revoked under 
a
particular CA cert.  Therefore, no parameters would be necessary - you 
would
be guaranteed to be able to establish if a particular client cert had ever
been revoked, and when.  Not sure if this suggestion is a winner, since 
for
very large and long term deployments, this CRL could be very large.  On 
the
other hand, only RPs that are verifying signatures on docs or transactions
after the cert has expired, would need to pull this down.  It would never 
be
needed for authentication activities, or for the period when the cert is
still valid.

Your discussion of parameters being supplied is probably a better approach
from a network performance perpective, since it provides a way for the RP
client application to be able to specify more tightly what revocation
information it is interested in, by perhaps supplying a date as a 
parameter
(as you suggest), or by presenting the client cert being verified and
letting the CA determine (by whatever means it decides to use) if the cert
had been revoked and when - then communicating that info back to the RP.
This is the tyoe of approach I meant to hint at in the list item (1).

Unfortunately, any work in this area would seem to require a change to
client applications.

If we want PKI to be able to service the signing and long term 
verification
of documents and transactions, we need some way of allowing an RP to be 
able
to get certificate status information, for a long time after the 
certificate
expired.  I cannot agree with Denis that it is the obligation of each RP 
to
archive such material for possible future use.  This is not user friendly,
and is in any case impractical for the vast majority of simple 
consumer-type
users who may be required to verify signatures over an extended period and
who (even if they did archive CRLs) may not be able to so if they somehow
lose the archived CRL (unless we also wanted to impose disaster revovery
requiremts on each simple consumer-type user).  Lets remeber that the I in
PKI is infrastructure - make provide the services that people need to be
able to carry on their normal lives without becoming computer wizards.

                 Regards
                 Dean


>         Dean:
>
>         I don't see how a full history CRL location would work without a
> parameter for the effective date.  FreshestCRL doesn't need such a
> parameter.  If we assumed that we want an "archivedCRL" accessMethod in
> AIA, how would the accessLocation represent the effective date 
parameter?
> I assume that it's appropriate for such an accessMethod to use HTTP or
> HTTPS.
>         An example of the URL for the actual query (for about now) would
> be:
>         https://www.publicCA.com/archivedCRL?date=200307301530Z
>         An RP actually using this feature would be able to construct the
> query by substituting the effective time into the URL.  I also would ask
> if we need variants of this for "last CRL not later than" and "first CRL
> not before".
>
>                 Tom Gindin
>
>
>
>
>
> "Dean Adams" <[e-mail]>
> Sent by: [e-mail]
> 07/29/2003 04:37 PM
>
>
>         To:     <[e-mail]>
>         cc:
>         Subject:        RE: Why is privateKeyUsagePeriod deprecated?
>
>
>
>
> Russ,
>                  Surely, merely finding some way to ensure that a CA
> archives CRLs is not
> enough.  Some way has to be provided to allow client applications to
> discover where the appropriate CRL to be checked, can be found.
>
> Some possible options for consideration:
> 1) the first CRL that was published after the
>    expiry date of the client cert being checked
> 2) the location of a fully maintained complete CRL
>    containing all history with regard to revoked certs
>    that were issued from a particular CA certificate
>
> I'm sure there are other options too, but in any case some means of
> communicating this info to the client application needs to be defined.
> Perhaps some certificate extension similar to "Freshest CRL" that 
instead
> denotes "FullHistory CRL" would be appropriate?  That (or something in
> Authority Info Access) might provide a solution for (2).  Not sure how 
you
> might go about providing a solution for a (1) type of approach, without
> getting overly complicated.
>
> Dean Adams
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Russ Housley
> Sent: 29 July 2003 16:56
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Why is privateKeyUsagePeriod deprecated?
>
>
>
> Peter:
>
> On one hand I agree, but on another I do not.
>
> I agree that signatures need to be validated after the certificate
> expires.
>
> The algorithm in RFC 3280 allows the certificate to be validate with
> respect to a date other than today.  The date that ought to be input
> requires a trusted time that the signature was applied.  Of course, PKIX
> has developed a protocol to provide such a time stamp.
>
> An archive of the revocation information is not routinely offered by
> CAs.  How do we make that happen?
>
> Russ
>
> At 01:32 AM 7/23/2003 +1200, Peter Gutmann wrote:
>
> >Stephen Kent <[e-mail]> writes:
> >
> > >I was not an author for 2459 or 3280, but my feeling is that we do 
not
> > >recommend use of PKUP for several reasons:
> >
> >But those are mostly just hypothetical objections.  At the moment we 
have
> two
> >inescapabable facts:
> >
> >1. CAs issue certs based on a 1-year billing cycle, and nothing anyone
> says
> >    will change that.  No CA will issue a cert with a 20-year lifetime,
> unless
> >    it's for its own CA certs.
> >
> >2. Users need to use certs to validate signatures at n times the
> CA-ordained
> >    lifetime.  In the abscence of any mechanism to do this, they are
> ignoring
> >    the cert expiry time.  In other words, out of necessity, they're
> > making the
> >    following change to RFC 3280:
> >
> >     The validity period for a certificate is the period of time from
> > notBefore
> >     through notAfter, inclusive.  When used with signing certificates,
> >     implementations SHOULD NOT pay any attention to the notAfter date.
> >
> >Given that this isn't going to change, it would seem that some guidance
> for
> >users would be useful here.  Since neither (1) nor (2) can be altered,
> what
> >would be needed is a simple extension, found in signing certs,
> containing
> a
> >date to which the cert can still be used for signature-checking beyond
> the
> >obvious notAfter value.  This could be written up as a short one-page
> >application note, no more (well, a bit more once you add all the usual
> >boilerplate and whatnot).
> >
> >Now CAs can still decide not to issue certs like that, but (a) they 
can't
> >justify it by claiming it screws up their standard cert cycle because 
it
> >doesn't affect validTo/validFrom, and (b) users at least have some
> guidance
> as
> >to what to do, which is better than the current situation where all 
they
> can
> >do is ignore parts of the standard on an ad hoc basis.
> >
> >Peter.
>
>
>
>
>
>