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

From: "Liaquat Khan" <[email-masked]>
Date: Sat, 30 Aug 2003 10:04:31 +0100

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: 29 August 2003 02:08
To: Faisal
Cc: Denis Pinkas; [email-masked]
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

From: "Liaquat Khan" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, "'Faisal'" <[email-masked]>
Cc: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Sat, 30 Aug 2003 10:04:31 +0100
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: 29 August 2003 02:08
To: Faisal
Cc: Denis Pinkas; [email-masked]
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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: AIA for SCVP
Date: Fri, 29 Aug 2003 12:33:36 -0700
Importance: Normal
Sender: [email-masked]

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

Michael Myers
(602) 739-7744

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Trevor Freeman
> Sent: Friday, August 29, 2003 11:14 AM
> To: Denis Pinkas
> Cc: Stephen Kent; Faisal; [email-masked]
> 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

Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 29 Aug 2003 11:13:38 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Faisal" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Friday, August 29, 2003 10:05 AM
To: Trevor Freeman
Cc: Stephen Kent; Faisal; [email-masked]
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: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: Thursday, August 28, 2003 6:08 PM
> To: Faisal
> Cc: Denis Pinkas; [email-masked]
> 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
> 

Date: Fri, 29 Aug 2003 19:04:52 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: Stephen Kent <[email-masked]>, Faisal <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: Thursday, August 28, 2003 6:08 PM
> To: Faisal
> Cc: Denis Pinkas; [email-masked]
> 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
> 

Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 29 Aug 2003 09:53:13 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Faisal" <[email-masked]>
Cc: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Thursday, August 28, 2003 6:08 PM
To: Faisal
Cc: Denis Pinkas; [email-masked]
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

Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
From: "Ryan M. Hurst" <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: "Terwilliger, Ann" <[email-masked]>, <[email-masked]>
Date: Thu, 28 Aug 2003 19:30:14 -0700
Sender: [email-masked]

--------------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; [email-masked]
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; [email-masked]<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--

Date: Thu, 28 Aug 2003 21:07:36 -0400
To: "Faisal" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 28 Aug 2003 21:02:36 -0400
To: "Ryan M. Hurst" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
Cc: "Terwilliger, Ann" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 28 Aug 2003 11:34:48 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Faisal <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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" <[email-masked]>
> To: "Faisal" <[email-masked]>
> Cc: <[email-masked]>
> 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: <[email-masked]>
>>>To: <IETF-Announce:>
>>>Cc: <[email-masked]>
>>>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:
>>>>[email-masked].
>>>>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.
>>>>
>>>
>>>
>>
> 
> 

From: "Faisal" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Thu, 28 Aug 2003 10:24:14 +0500
Sender: [email-masked]

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" <[email-masked]>
To: "Faisal" <[email-masked]>
Cc: <[email-masked]>
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: <[email-masked]>
> > To: <IETF-Announce:>
> > Cc: <[email-masked]>
> > 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:
> >>[email-masked].
> >>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.
> >>
> >
> >
>
>

Content-class: urn:content-classes:message
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
Date: Wed, 27 Aug 2003 15:22:43 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Terwilliger, Ann" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Terwilliger, Ann
Sent: Wednesday, August 27, 2003 11:26 AM
To: [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 22, 2003 7:59 AM
Cc: [email-masked]
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

Date: Wed, 27 Aug 2003 12:08:38 -0400
From: Rich Salz <[email-masked]>
To: "Deacon, Alex" <[email-masked]>
CC: "'Ryan M. Hurst'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt
Sender: [email-masked]

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

From: "Peter Hesse" <[email-masked]>
To: "'Terwilliger, Ann'" <[email-masked]>, <[email-masked]>
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.
Importance: Normal
Sender: [email-masked]

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                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Terwilliger, Ann
Sent: Wednesday, August 27, 2003 2:26 PM
To: [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 22, 2003 7:59 AM
Cc: [email-masked]
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

Date: Wed, 27 Aug 2003 15:04:11 -0400
To: "Terwilliger, Ann" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID m atching)
Cc: [email-masked]
Sender: [email-masked]

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

From: "Terwilliger, Ann" <[email-masked]>
To: [email-masked]
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
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 22, 2003 7:59 AM
Cc: [email-masked]
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

Date: Wed, 27 Aug 2003 12:08:38 -0400
From: Rich Salz <[email-masked]>
To: "Deacon, Alex" <[email-masked]>
CC: "'Ryan M. Hurst'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-proxy-08.txt
Date: Wed, 27 Aug 2003 10:27:30 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-proxy-08.txt
Date: Wed, 27 Aug 2003 10:27:30 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 27 Aug 2003 15:39:06 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Faisal <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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: <[email-masked]>
> To: <IETF-Announce:>
> Cc: <[email-masked]>
> 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:
>>[email-masked].
>>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.
>>
> 
> 

Date: Wed, 27 Aug 2003 15:33:35 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Matt Cooper <[email-masked]>
CC: "'PKIX List'" <[email-masked]>
Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
Sender: [email-masked]

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:[email-masked]] 
>>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
>>
> 
> 
> 

Date: Wed, 27 Aug 2003 00:13:04 +0200
From: Leif Johansson <[email-masked]>
To: Peter Gietz <[email-masked]>
CC: Stephen Kent <[email-masked]>, todd glassey <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

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

Date: Fri, 22 Aug 2003 13:15:31 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID 	 matching)
Cc: [email-masked]
Sender: [email-masked]

At 14:59 +0000 8/22/03, [email-masked] 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

From: "Peter Hesse" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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.
Importance: Normal
Sender: [email-masked]

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                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Friday, August 22, 2003 10:59 AM
To: [email-masked]
Cc: [email-masked]
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

From: [email-masked]
Cc: [email-masked]
Date: Fri, 22 Aug 2003 14:59:08 +0000
Subject: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID matching)
Sender: [email-masked]

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

From: Tim Moses <[email-masked]>
To: "'L Williams'" <[email-masked]>, "'Steve Hanna'" <[email-masked]>
Cc: [email-masked]
Subject: RE: 3280 Question WRT SKID/AKID matching
Date: Fri, 22 Aug 2003 09:08:05 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, August 21, 2003 3:59 PM
To: 'Steve Hanna'
Cc: [email-masked]
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

Date: Fri, 22 Aug 2003 11:55:16 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: 3280 Question WRT SKID/AKID matching
Sender: [email-masked]

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.

From: "Peter Hesse" <[email-masked]>
To: "'L Williams'" <[email-masked]>, "'Steve Hanna'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: 3280 Question WRT SKID/AKID matching
Date: Thu, 21 Aug 2003 21:38:03 -0400
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of L Williams
Sent: Thursday, August 21, 2003 3:59 PM
To: 'Steve Hanna'
Cc: [email-masked]
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

Date: Thu, 21 Aug 2003 17:34:19 -0400
To: "Manger, James H" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: IP addr: 01: WG last call
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "L Williams" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: 3280 Question WRT SKID/AKID matching
Date: Thu, 21 Aug 2003 12:59:29 -0700
Importance: Normal
Sender: [email-masked]

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

Date: Thu, 21 Aug 2003 10:32:31 -0400
From: Steve Hanna <[email-masked]>
To: Matt Cooper <[email-masked]>
CC: [email-masked]
Subject: Re: 3280 Question WRT SKID/AKID matching
Sender: [email-masked]

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

--------------ms6A4FDACAA5F48CEEF681EBC9--

content-class: urn:content-classes:message
Subject: RE: IP addr: 01: WG last call
Date: Thu, 21 Aug 2003 10:13:54 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
	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.

From: "Matt Cooper" <[email-masked]>
To: <[email-masked]>
Subject: 3280 Question WRT SKID/AKID matching
Date: Wed, 20 Aug 2003 12:18:56 -0400
Importance: Normal
Sender: [email-masked]

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

Date: Tue, 19 Aug 2003 22:02:06 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: WG last call
Sender: [email-masked]

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

From: "Deacon, Alex" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, Rich Salz <[email-masked]>, "Deacon, Alex" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
Date: Mon, 18 Aug 2003 10:05:37 -0700
Sender: [email-masked]

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:[email-masked]]
Sent: Monday, August 18, 2003 8:07 AM
To: Rich Salz; Deacon, Alex
Cc: [email-masked]; [email-masked]
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; [email-masked]; [email-masked]
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:[email-masked]]<BR><B>Sent:</B> Monday, August 18, 2003 
  8:07 AM<BR><B>To:</B> Rich Salz; Deacon, Alex<BR><B>Cc:</B> [email-masked]; 
  [email-masked]<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; 
  [email-masked]; [email-masked]<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--

Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
From: "Ryan M. Hurst" <[email-masked]>
To: Rich Salz <[email-masked]>, "Deacon, Alex" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Mon, 18 Aug 2003 08:07:14 -0700
Sender: [email-masked]

<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=
[email-masked]; [email-masked]<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>

Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
From: "Ryan M. Hurst" <[email-masked]>
To: dan ash <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Mon, 18 Aug 2003 08:00:06 -0700
Sender: [email-masked]

--------------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: [email-masked]; [email-masked]
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 [email-masked] 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> [email-masked]; w=
[email-masked]<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--

Date: Fri, 15 Aug 2003 21:12:18 -0400 (EDT)
From: Rich Salz <[email-masked]>
To: "Deacon, Alex" <[email-masked]>
cc: "'Ryan M. Hurst'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
Sender: [email-masked]

> 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

Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
From: "Ryan M. Hurst" <[email-masked]>
To: "Deacon, Alex" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Fri, 15 Aug 2003 17:44:29 -0700
Sender: [email-masked]

--------------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: [email-masked]; [email-masked]
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:[email-masked]]
> Sent: Monday, August 04, 2003 11:08 AM
> To: Deacon, Alex
> Cc: [email-masked]
> 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: [email-masked]=20
> [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Monday, August 04, 2003 7:14 AM
> Cc: [email-masked]
> 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:
> 	[email-masked].
> 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>=
 [email-masked]; [email-masked]<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:[email-masked]]
&gt; Sent: Monday, August 04, 2003 11:08 AM
&gt; To: Deacon, Alex
&gt; Cc: [email-masked]
&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: [email-masked]=20
&gt; [mailto:[email-masked]]
&gt; On Behalf Of [email-masked]
&gt; Sent: Monday, August 04, 2003 7:14 AM
&gt; Cc: [email-masked]
&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; 	[email-masked].
&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--

From: "Deacon, Alex" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, "Deacon, Alex" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
Date: Fri, 15 Aug 2003 17:09:22 -0700
Sender: [email-masked]

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:[email-masked]]
> Sent: Monday, August 04, 2003 11:08 AM
> To: Deacon, Alex
> Cc: [email-masked]
> 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: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Monday, August 04, 2003 7:14 AM
> Cc: [email-masked]
> 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:
> 	[email-masked].
> 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.
> 
> 

From: "Matt Cooper" <[email-masked]>
To: "'Masaki SHIMAOKA'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 14 Aug 2003 17:59:26 -0400
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Masaki SHIMAOKA
> Sent: Tuesday, July 22, 2003 11:12 PM
> To: [email-masked]
> 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: +81 422 91 8493 (ext.3551)
> Fax: +81 422 45 0536
> e-mail: [email-masked]
> 

From: "Matt Cooper" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'Steve Hanna'" <[email-masked]>, "'PKIX List'" <[email-masked]>, "'Peter Hesse'" <[email-masked]>, "'Yuriy Dzambasow'" <[email-masked]>, "'Susan Joseph'" <[email-masked]>, "'Richard E. Nicholas \(Nicholas, Richard\)'" <[email-masked]>
Subject: RE: draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 14 Aug 2003 15:32:23 -0400
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
> 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
> 

From: "todd glassey" <[email-masked]>
To: "Peter Gietz" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Wed, 13 Aug 2003 08:05:43 -0700
Sender: [email-masked]

it is peter and your comments are dead on.

Todd
----- Original Message ----- 
From: "Peter Gietz" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "todd glassey" <[email-masked]>; "Peter Gutmann"
<[email-masked]>; <[email-masked]>
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: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

From: "todd glassey" <[email-masked]>
To: <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Date: Wed, 13 Aug 2003 08:44:24 -0700
Sender: [email-masked]

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: [email-masked]=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: [email-masked]
  [mailto:[email-masked]]On Behalf Of Denis Pinkas
  Sent: Tuesday, July 29, 2003 6:38 AM
  To: [email-masked]
  Cc: [email-masked]
  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=[email-masked] =
href=3D"mailto:[email-masked]">Alice=20
  Sturgeon</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Denis Pinkas</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]=
</A><BR>[<A=20
  =
href=3D"mailto:[email-masked]">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
  [email-masked]<BR>Cc: [email-masked]<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--

From: "todd glassey" <[email-masked]>
To: "Peter Gietz" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Wed, 13 Aug 2003 08:05:43 -0700
Sender: [email-masked]

it is peter and your comments are dead on.

Todd
----- Original Message ----- 
From: "Peter Gietz" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "todd glassey" <[email-masked]>; "Peter Gutmann"
<[email-masked]>; <[email-masked]>
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: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

From: "todd glassey" <[email-masked]>
To: "Peter Gietz" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Wed, 13 Aug 2003 08:05:43 -0700
Sender: [email-masked]

it is peter and your comments are dead on.

Todd
----- Original Message ----- 
From: "Peter Gietz" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "todd glassey" <[email-masked]>; "Peter Gutmann"
<[email-masked]>; <[email-masked]>
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: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

From: "Faisal" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 13 Aug 2003 16:38:57 +0500
Sender: [email-masked]

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: <[email-masked]>
To: <IETF-Announce:>
Cc: <[email-masked]>
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:
> [email-masked].
> 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"

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

Date: Wed, 13 Aug 2003 12:21:58 +0200
From: Peter Gietz <[email-masked]>
Organization: DAASI International GmbH
To: Stephen Kent <[email-masked]>
CC: todd glassey <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

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: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

Reply-To: <[email-masked]>
From: "Alice Sturgeon" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Date: Wed, 13 Aug 2003 06:10:06 -0400
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Denis Pinkas
Sent: Tuesday, July 29, 2003 6:38 AM
To: [email-masked]
Cc: [email-masked]
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
[email-masked]<BR>[<A=20
href=3D"mailto:[email-masked]">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
[email-masked]<BR>Cc: [email-masked]<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--

From: "todd glassey" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Tue, 12 Aug 2003 15:21:08 -0700
Sender: [email-masked]

Phillip -
----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
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

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)
Date: Tue, 12 Aug 2003 12:41:37 -0700
Sender: [email-masked]

> 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

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Last Call: 'Internet X.509 Public Key Infrastructure Warranty  Certificate Extension' to Informational RFC 
Reply-To: [email-masked]
Date: Tue, 12 Aug 2003 14:44:07 -0400
Sender: [email-masked]

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
[email-masked] or [email-masked] 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

To: IETF-Announce :;
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Last Call: 'Internet X.509 Public Key Infrastructure Warranty  Certificate Extension' to Informational RFC 
Reply-to: [email-masked]
Date: Tue, 12 Aug 2003 14:44:07 -0400
Sender: [email-masked]

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
[email-masked] or [email-masked] 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

From: The IESG <[email-masked]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, <[email-masked]>
Subject: Document Action: 'Policy Requirements for Time-Stamping  Authorities' to Informational RFC 
Date: Mon, 11 Aug 2003 16:02:10 -0400
Sender: [email-masked]

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.

Date: Sat, 09 Aug 2003 11:38:05 +0200
From: Leif Johansson <[email-masked]>
To: David Chadwick <[email-masked]>
CC: [email-masked], "'PKIX'" <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Sender: [email-masked]

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

Date: Fri, 08 Aug 2003 22:28:05 +0200
From: Leif Johansson <[email-masked]>
To: David Chadwick <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

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

Date: Thu, 7 Aug 2003 16:59:06 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: first comments for SCVP 12
Sender: [email-masked]

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

From: Sharon Boeyen <[email-masked]>
To: "Steve Hanna (E-mail)" <[email-masked]>, "pkix (E-mail)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: FW:Resend  PKIX LDAPv3 schema: component matching or separate ent ries
Date: Thu, 7 Aug 2003 10:33:07 -0400 
Sender: [email-masked]

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:[email-masked]]
Sent: Tuesday, August 05, 2003 3:21 PM
To: PKIX List; [email-masked]
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

From: Sharon Boeyen <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>, PKIX List <[email-masked]>, [email-masked]
Subject: RE: PKIX LDAPv3 schema: component matching or separate entries
Date: Thu, 7 Aug 2003 09:43:12 -0400 
Sender: [email-masked]

Date: Tue, 05 Aug 2003 14:23:22 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: Leif Johansson <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Tue, 05 Aug 2003 13:54:40 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: [email-masked]
CC: "'PKIX'" <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Sender: [email-masked]

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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Tue, 05 Aug 2003 13:56:16 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: [email-masked]
CC: "'PKIX'" <[email-masked]>
Subject: Re: LDAPv3 Profile Issue
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 01484 532930
> > Mobile: +44 77 96 44 7184
> > Email: [email-masked]
> > 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: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Tue, 05 Aug 2003 15:20:34 -0400
From: Steve Hanna <[email-masked]>
To: PKIX List <[email-masked]>, [email-masked]
Subject: PKIX LDAPv3 schema: component matching or separate entries
Sender: [email-masked]

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

--------------msA8B46CA38210A350F106092D--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-pr-tsa-05.txt
Date: Tue, 05 Aug 2003 10:15:27 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Anders Rundgren" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Date: Tue, 5 Aug 2003 11:49:57 +0200
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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

Reply-To: <[email-masked]>
From: "Steven Legg" <[email-masked]>
To: "'Michael Str der'" <[email-masked]>
Cc: "'PKIX'" <[email-masked]>
Subject: RE: Issues in LDAP schema IDs
Date: Tue, 5 Aug 2003 10:00:23 +1000
Importance: Normal
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
Date: Mon, 4 Aug 2003 11:07:48 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Deacon, Alex" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, August 04, 2003 7:14 AM
Cc: [email-masked]
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:
	[email-masked].
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.

Date: Mon, 4 Aug 2003 18:47:57 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: first comments for SCVP 12
Sender: [email-masked]

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

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt
Date: Mon, 04 Aug 2003 10:14:21 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: Comments on draft-ietf-pkix-sonof3039-01.txt
Date: Mon, 4 Aug 2003 11:00:34 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Jim,

Thank you very much for this review.

I will fix in the next version.

/Stefan

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: den 31 juli 2003 03:12
To: Stefan Santesson
Cc: [email-masked]
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

From: <[email-masked]>
To: <[email-masked]>
Subject: RE: Why is privateKeyUsagePeriod deprecated?
Date: Sat, 2 Aug 2003 14:43:33 +0200
Importance: Normal
Sender: [email-masked]

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:[email-masked]]

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

> To: [email-masked]

> Cc: [email-masked]

> 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:[email-masked]]</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: [email-masked]</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: [email-masked]</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--

From: Sharon Boeyen <[email-masked]>
To: "pkix (E-mail)" <[email-masked]>
Subject: Multi-valued RDNs
Date: Fri, 1 Aug 2003 11:54:03 -0400 
Sender: [email-masked]

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: 613 270 3181
Fax: 613 270 2504 
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: 613 270 3181</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Fax: 613 270 2504 </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--

From: "Dean Adams" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: <[email-masked]>
Subject: Closure of: Why is privateKeyUsagePeriod deprecated?
Date: Fri, 1 Aug 2003 16:34:21 +0100
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Tom Gindin
> Sent: 01 August 2003 12:26
> To: Dean Adams
> Cc: [email-masked]
> 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" <[email-masked]>
> 07/31/2003 06:42 AM
>
>
>         To:     Tom Gindin/Watson/IBM@IBMUS
>         cc:     <[email-masked]>
>         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" <[email-masked]>
> > Sent by: [email-masked]
> > 07/29/2003 04:37 PM
> >
> >
> >         To:     <[email-masked]>
> >         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: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Russ Housley
> > Sent: 29 July 2003 16:56
> > To: [email-masked]
> > Cc: [email-masked]
> > 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 <[email-masked]> 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.
> >
> >
> >
> >
> >
> >
>
>
>
>
>

Date: Fri, 1 Aug 2003 10:23:07 -0400
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)
Cc: "Peter Gutmann" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 01 Aug 2003 15:14:59 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Cc: "'PKIX'" <[email-masked]>
Subject: Re: Issues in LDAP schema IDs
Sender: [email-masked]

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.

To: "Dean Adams" <[email-masked]>
Cc: [email-masked]
Subject: RE: Why is privateKeyUsagePeriod deprecated?
From: Tom Gindin <[email-masked]>
Date: Fri, 1 Aug 2003 07:26:13 -0400
Sender: [email-masked]

        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" <[email-masked]>
07/31/2003 06:42 AM

        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     <[email-masked]>
        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" <[email-masked]>
> Sent by: [email-masked]
> 07/29/2003 04:37 PM
>
>
>         To:     <[email-masked]>
>         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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Russ Housley
> Sent: 29 July 2003 16:56
> To: [email-masked]
> Cc: [email-masked]
> 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 <[email-masked]> 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.
>
>
>
>
>
>