Subject: What does the 'S' in SCVP stand for?

From: "James Jing" <[email-masked]>
Date: Mon, 31 May 2004 16:21:59 +1000

Looking at latest draft of SCVP (14), one starts to wonder whether the
letter 'S' in SCVP stands for 'Simple', or it has mutated into
'Superfluous'.

We implemented SCVP for one of our customers way back when SCVP was in
draft 8. Then and now I see the reason for the existence of SCVP is that
a client application wants to defer to the server to make the decision
on the validity of a certificate which has been presented. With the
request object becoming as complex as it is now, one wonders whether the
client application is actually better off doing all on its own. 

If the purpose is to provide validation logic to another application, I
would argue that one is better off using a library, rather than a
client-server proposition with a complex protocol. Maybe I am the only
guy feeling this way.

James

content-class: urn:content-classes:message
Subject: What does the 'S' in SCVP stand for?
Date: Mon, 31 May 2004 16:21:59 +1000
From: "James Jing" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Looking at latest draft of SCVP (14), one starts to wonder whether the
letter 'S' in SCVP stands for 'Simple', or it has mutated into
'Superfluous'.

We implemented SCVP for one of our customers way back when SCVP was in
draft 8. Then and now I see the reason for the existence of SCVP is that
a client application wants to defer to the server to make the decision
on the validity of a certificate which has been presented. With the
request object becoming as complex as it is now, one wonders whether the
client application is actually better off doing all on its own. 

If the purpose is to provide validation logic to another application, I
would argue that one is better off using a library, rather than a
client-server proposition with a complex protocol. Maybe I am the only
guy feeling this way.

James

Date: Fri, 28 May 2004 18:47:23 -0700
From: Ed Gerck <[email-masked]>
To: Tony Bartoletti <[email-masked]>
CC: Dave Engberg <[email-masked]>, PKIX <[email-masked]>
Subject: Re: New ID: draft-gerck-pkix-revocation-00.txt
Sender: [email-masked]

Tony Bartoletti wrote:
> Should the RP desire certifications that limit the "window of 
> opportunity" to 5 minutes, they must reject certifications made by CA's 
> that do not support sufficient timeliness. 

Yes. This can be easily automated by the RP by using the freshestCRL field,
for example. If the CRL was issued more than 5 minutes ago, wait for the
next CRL and decide within 5 minutes of its publication.

 > "Let the RP beware".

Yes, "Let the RP beware" because RP reliance is that which can break the RP's
security policy (Section 2 of the ID). The revocation status of a cert depends
both on processes that the RP CAN verify and processes that the RP CANNOT
verify. The latter defines the limitations of RP reliance. The lesser the
limitations of RP reliance, the lesser the risk faced by the RP that RP
reliance might be broken by factors outside RP control.

Cheers,
Ed Gerck

Date: Fri, 28 May 2004 18:35:56 -0700
From: Ed Gerck <[email-masked]>
To: Dave Engberg <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: New ID: draft-gerck-pkix-revocation-00.txt
Sender: [email-masked]

Dave Engberg wrote:

> 
> Ed -
> 
> Thanks for putting together this revocation memo.  This provides a very
> useful philosophical analysis for PKI architectures.

I hope it's more practical than philosophical ;-)

The  philosophical aspect might be that because similar issues can be recognized
in other areas, the memo benefits from their solutions. For example, when
verifying the revocation status of a cert for a given time T, what does it mean
to require that two different RPs shall come to the same result for the same time
T? It means that the revocation status shall be an objective reference. Which
introduces some requirements, one of which is observability.

> To paraphrase one of the central arguments (section 3.1.2):  the
> objective revocation of a certificate is (basically) defined as the
> first instant of publication of a corresponding CRL (or Delta CRL, OCSP
> response, etc.) by the cert's issuer.  You separate this definition of
> revocation from the more ambiguous processes of checking revocation
> through all of our non-transactional PKI protocols.
> 
> I'm interested to hear why you chose to define "objectively revoked" in
> terms of the completion of publication rather than the moment of
> notification to the CA.

First, we need to distinguish between "notice" and "status" (perhaps a new
item to be discussed in the ID). The moment of notification to the CA is a
notice. For example, a request for revocation sent by the subscriber. A
revocation notice is NOT the revocation status, and is also NOT that status
available as an observable entity. The certificate's status changes NOT when
the notice is received but when the CRL is published. Moreover, in  order
to be objective, the revocation status needs to be observable -- for example,
the published status must be readable by an RP.

> Consider:  I'm familiar with a large PKI that used to require a few
> hours to produce a CRL.  If the CA was notified of a revocation at 9am,
> the first external communication about this revocation would only be
> available in the afternoon.

As defined in the freshestCRL field, for example.

> If you asked the administrators of this PKI, they would have intuitively
> felt that the cert was "really" revoked at 9am, and that the latency
> between this time and the first publication was just a propogation delay
> for the objective reality.

This is exactly what the ID clarifies: the cert was not revoked at 9am. The
event that can be observed by any RP is the first external communication
about this revocation, which would only be available in the afternoon
according to your example.

> Obviously, this is an extreme example, but there will always be some
> latency between a CA's notification of revocation and when that
> information propogates to Relying Parties.  

Yes, this is discussed in section 4.6, "Increasing Reliability",
which also discusses how the latency can be reduced or, at least,
bounded.

> I'm curious why you put part
> of this latency (production of the CRL) before the "objective
> revocation" and parts of it (distribution to LDAP directories, OCSP
> responders, transmission to RPs) after the objective moment of
> revocation.

Because the latency that corresponds to the "notice" process (including
production of the CRL and the delay for its publication in the next update)
cannot be reduced by any efforts of the RP. The RP is entirely at the
mercy of the CRL issuer for this part. OTOH, after the objective moment
of revocation (i.e., the revocation status "revoked" is observable by
any RP), additional efforts by an RP should increase the ability of the
RP to make a reliance determination of a certificate's revocation status
in less time.

Cheers,
Ed Gerck

Date: Fri, 28 May 2004 17:16:19 -0700
To: "Dave Engberg" <[email-masked]>, "Ed Gerck" <[email-masked]>, "PKIX" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: New ID: draft-gerck-pkix-revocation-00.txt
Sender: [email-masked]

At 01:12 PM 5/28/2004, Dave Engberg wrote:

>Ed -
>
>I'm interested to hear why you chose to define "objectively revoked" in
>terms of the completion of publication rather than the moment of
>notification to the CA.

Dare I speak for Ed on this matter ... :)

I may feel I have notified my CA of (compromise, revocation desire, etc) at 
time T.

The CA is free to take this into consideration, according to their own 
processes.  Those processes are (and perhaps should be) quite opaque to 
outsiders.  The world of RPs who may rely upon that certificate must, of 
necessity, depend upon a notification made by the CA.  From a strictly 
formal standpoint, the certificate is not revoked when the CA "feels" is it 
revoked, but only when the CA SAYS it is revoked.  They are the only 
authority in this matter.

It might be "nice" if such notifications included "reason", indicating 
(perhaps) "report of compromise at time T".  But really, what CA would want 
to open itself to such (potential) liability?  Of what other value (except 
to put the CA into hot water) would one desire to learn that a certificate, 
revoked this moment but relied upon 1 hour ago, was reported compromised 2 
hours earlier?

 From the RP standpoint, it was reasonable and "right" to rely upon it 1 
hour ago, in any case.

Should the RP desire certifications that limit the "window of opportunity" 
to 5 minutes, they must reject certifications made by CA's that do not 
support sufficient timeliness.  "Let the RP beware".

Cheers!   ____tony____

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

Content-class: urn:content-classes:message
Subject: RE: New ID: draft-gerck-pkix-revocation-00.txt
Date: Fri, 28 May 2004 16:12:25 -0400
From: "Dave Engberg" <[email-masked]>
To: "Ed Gerck" <[email-masked]>, "PKIX" <[email-masked]>
Sender: [email-masked]

Ed -

Thanks for putting together this revocation memo.  This provides a very
useful philosophical analysis for PKI architectures.

To paraphrase one of the central arguments (section 3.1.2):  the
objective revocation of a certificate is (basically) defined as the
first instant of publication of a corresponding CRL (or Delta CRL, OCSP
response, etc.) by the cert's issuer.  You separate this definition of
revocation from the more ambiguous processes of checking revocation
through all of our non-transactional PKI protocols.

I'm interested to hear why you chose to define "objectively revoked" in
terms of the completion of publication rather than the moment of
notification to the CA.

Consider:  I'm familiar with a large PKI that used to require a few
hours to produce a CRL.  If the CA was notified of a revocation at 9am,
the first external communication about this revocation would only be
available in the afternoon.

If you asked the administrators of this PKI, they would have intuitively
felt that the cert was "really" revoked at 9am, and that the latency
between this time and the first publication was just a propogation delay
for the objective reality.

Obviously, this is an extreme example, but there will always be some
latency between a CA's notification of revocation and when that
information propogates to Relying Parties.  I'm curious why you put part
of this latency (production of the CRL) before the "objective
revocation" and parts of it (distribution to LDAP directories, OCSP
responders, transmission to RPs) after the objective moment of
revocation.

Thanks,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ed Gerck
Sent: Thursday, May 27, 2004 8:56 PM
To: PKIX
Subject: New ID: draft-gerck-pkix-revocation-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is an individual submission in reference to the Public-Key
Infrastructure
(X.509) Working Group of the IETF.

	Title		: Certificate Revocation Revisited
	Author(s)	: E. Gerck
	Filename	: draft-gerck-pkix-revocation-00.txt

...

Date: Fri, 28 May 2004 15:17:42 +0000
To: "Ietf-pkix" <[email-masked]>
From: "Wpolk" <[email-masked]>
Subject: Re: Yahoo!
Sender: [email-masked]

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

<html><body>
<img src="cid:xqhefahjla.bmp"><br>
</body></html>

----------uodsczvswnvsowywinur
Content-Type: image/bmp; name="xqhefahjla.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="xqhefahjla.bmp"
Content-ID: 

----------uodsczvswnvsowywinur
Content-Type: application/octet-stream; name="Information.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Information.zip"

----------uodsczvswnvsowywinur--

Reply-To: "Manuel Gil Perez" <[email-masked]>
From: "Manuel Gil Perez" <[email-masked]>
To: <[email-masked]>
Subject: Renewal or Re-keying services into CMC protocol
Date: Fri, 28 May 2004 14:45:21 +0200
Organization: ANTS Research Group
Sender: [email-masked]

Hi everyone.

I'm implementing the CMC protocol and I've several doubts about renewal and
re-keing services. The protocol specifies that "a renewal/re-key message
looks the same as any enrollment message, with the identity proof being
supplied by existing certificates from the CA". For instance, when I like to
make a renewal request it's a few unreasonable I create a enrollment message
with data of the client certificate because for any LRA/RA this
certification request doesn't serve for nothing.

On the other hand, I can still send a Full PKI Request message with the
PKIData sequence empty, but it seems unsuitable too. Even, how I can know
the kind of message (renewal or re-keing) from the server side??

For a re-key message, the problem is the same. What should I do??

>From my honest opinion, I would created a new type of message for these
services.

Thanks a lot!

  Manuel Gil.-

---
Information extracted from the RFC 2797:

 * No special services are provided for doing either renewal (new
certificates
 * with the same key) or re-keying (new certificates on new keys) of
clients.
 * Instead a renewal/re-key message looks the same as any enrollment
message,
 * with the identity proof being supplied by existing certificates from the
CA.
 *
 * In a renewal or re-key message, the subject DN in (a) the certificate
 * referenced by the CMS SignerInfo object, and (b) all certificate requests
 * within the request message MUST match according to the standard.

Date: Thu, 27 May 2004 17:55:46 -0700
From: Ed Gerck <[email-masked]>
To: PKIX <[email-masked]>
Subject: New ID: draft-gerck-pkix-revocation-00.txt
Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is an individual submission in reference to the Public-Key Infrastructure
(X.509) Working Group of the IETF.

	Title		: Certificate Revocation Revisited
	Author(s)	: E. Gerck
	Filename	: draft-gerck-pkix-revocation-00.txt
	Pages		: 17
	Date		: 2004-5-24

ABSTRACT:	
PKIX certificate revocation protocols are primarily described in RFC3280.
This Document revisits limitations on determining the revocation status
of a certificate. Ambiguous aspects of revocation and revocation delegation
are resolved. An objective point of view is introduced as a reference
that does not depend on the observer (e.g., the RP). The revocation
status of a certificate issued by a conforming CA is shown to be always
well-defined from a relying party's point of view -- i.e., it is
unambiguous (revoked or not revoked) and ultimately determinable at any
period in time. The limitations on determining the revocation status of
a certificate have nothing to do with the eventual result of the
determination process by a relying party. The limitations have to do
with the efforts for that determination, which may require a large
(actually unspecified) amount of time and work. Some practices are also
suggested, allowing a relying party to determine the revocation status
of a certificate with higher reliability in less time. The same
considerations apply to determinations of status "change" processes,
including certificateHold and removefromCRL.

A URL for this Internet-Draft is:
http://ietf.org/internet-drafts/draft-gerck-pkix-revocation-00.txt

Comments are welcome.

Cheers,
Ed Gerck

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Al Arsenault'" <[email-masked]>, "Aisenberg, Michael" <[email-masked]>, "'Dino Esposito'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: PKIX Roadmap
Date: Thu, 27 May 2004 17:08:11 -0700
Sender: [email-masked]

> It was never published as an RFC, because it was intended to 
> be a "living document" that reflected the ongoing status of 
> the working group.  The IESG ruled that such a document could 
> not be published as an RFC - it has references to too many 
> "works in progress".

This is like the folk who feel the need to add postscripts to
emails. The whole point of Requests For Comments was that they
would represent works in progress.

The idea was that the Internet represented a work in progress
rather than a destination.

It seems a little silly to have RFCs that describe transport of
IP packets by pidgeon but not information that might be useful.

	Phill

Date: Thu, 27 May 2004 15:42:27 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: Al Arsenault <[email-masked]>
CC: "Aisenberg, Michael" <[email-masked]>, "'Dino Esposito'" <[email-masked]>, [email-masked]
Subject: Re: PKIX Roadmap
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Al&nbsp; - you pretty much summariezed what happened.<br>
<br>
spt<br>
<br>
Al Arsenault wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">
  <pre wrap="">Hm, the I-D seems to have aged off the server.

It was never published as an RFC, because it was intended to be a "living document" that reflected the ongoing status of the working group.  The IESG ruled that such a document could not be published as an RFC - it has references to too many "works in progress".

Maybe if we get time, we'll have to figure out how to update it as a "postmortem" of the PKIX working group.

(Although my name is still on it as an author, Sean Turner has been primary author for quite a few versions.  Sean, any comments?)

		Al Arsenault
		BBN Technologies

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]On Behalf Of Aisenberg, Michael
Sent: Thursday, May 27, 2004 2:54 PM
To: 'Dino Esposito'; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: RE: PKIX Roadmap

good question--

please share answer....

Michael Aisenberg
VeriSign/Washington D.C.

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> 
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] On
Behalf Of Dino Esposito
Sent: Thursday, May 27, 2004 12:38 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: PKIX Roadmap

Hi all
in the PKIX charter web page is written
"A roadmap, providing a guide to the growing set of PKIX document, also
has been developed as an informational RFC".

I was not able to find this RFC.
Where can I find it?
Thank you

Alfredo Esposito
InfoCamere S.C.p.A.
Information Security Department
Roma
Italy
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>

From: "Al Arsenault" <[email-masked]>
To: "Aisenberg, Michael" <[email-masked]>, "'Dino Esposito'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: PKIX Roadmap
Date: Thu, 27 May 2004 15:19:08 -0400
Importance: Normal
Sender: [email-masked]

Hm, the I-D seems to have aged off the server.

It was never published as an RFC, because it was intended to be a "living document" that reflected the ongoing status of the working group.  The IESG ruled that such a document could not be published as an RFC - it has references to too many "works in progress".

Maybe if we get time, we'll have to figure out how to update it as a "postmortem" of the PKIX working group.

(Although my name is still on it as an author, Sean Turner has been primary author for quite a few versions.  Sean, any comments?)

		Al Arsenault
		BBN Technologies

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Aisenberg, Michael
> Sent: Thursday, May 27, 2004 2:54 PM
> To: 'Dino Esposito'; [email-masked]
> Subject: RE: PKIX Roadmap
> 
> 
> 
> good question--
> 
> please share answer....
> 
> Michael Aisenberg
> VeriSign/Washington D.C.
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On
> Behalf Of Dino Esposito
> Sent: Thursday, May 27, 2004 12:38 PM
> To: [email-masked]
> Subject: PKIX Roadmap
> 
> 
> Hi all
> in the PKIX charter web page is written
> "A roadmap, providing a guide to the growing set of PKIX document, also
> has been developed as an informational RFC".
> 
> I was not able to find this RFC.
> Where can I find it?
> Thank you
> 
> Alfredo Esposito
> InfoCamere S.C.p.A.
> Information Security Department
> Roma
> Italy

From: "Aisenberg, Michael" <[email-masked]>
To: "'Dino Esposito'" <[email-masked]>, [email-masked]
Subject: RE: PKIX Roadmap
Date: Thu, 27 May 2004 14:54:06 -0400
Sender: [email-masked]

good question--

please share answer....

Michael Aisenberg
VeriSign/Washington D.C.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dino Esposito
Sent: Thursday, May 27, 2004 12:38 PM
To: [email-masked]
Subject: PKIX Roadmap

Hi all
in the PKIX charter web page is written
"A roadmap, providing a guide to the growing set of PKIX document, also
has been developed as an informational RFC".

I was not able to find this RFC.
Where can I find it?
Thank you

Alfredo Esposito
InfoCamere S.C.p.A.
Information Security Department
Roma
Italy

Date: Thu, 27 May 2004 18:37:33 +0200
From: Dino Esposito <[email-masked]>
To: [email-masked]
Subject: PKIX Roadmap
Sender: [email-masked]

Hi all
in the PKIX charter web page is written
"A roadmap, providing a guide to the growing set of PKIX document, also
has been developed as an informational RFC".

I was not able to find this RFC.
Where can I find it?
Thank you

Alfredo Esposito
InfoCamere S.C.p.A.
Information Security Department
Roma
Italy

To: IETF-Announce: ;
Subject: RFC 3770 on Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Wed, 26 May 2004 16:09:41 -0700
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3770

        Title:      Certificate Extensions and Attributes Supporting
                    Authentication in Point-to-Point Protocol (PPP)
                    and Wireless Local Area Networks (WLAN)
        Author(s):  R. Housley, T. Moore
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    [email-masked], [email-masked]
        Pages:      9
        Characters: 18635
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-wlan-extns-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3770.txt

This document defines two EAP extended key usage values and a public
key certificate extension to carry Wireless LAN (WLAN) System Service
identifiers (SSIDs).

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

RETRIEVE: rfc
DOC-ID: rfc3770

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3770.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--

Date: Mon, 24 May 2004 09:49:28 +0530
To: "Ietf-pkix" <[email-masked]>
From: "Wpolk" <[email-masked]>
Subject: Protected message
Sender: [email-masked]

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

<html><body>
<img src="cid:tdtqilgjhu.gif"><br>
</body></html>

----------yynbceeefnexpyuconyr
Content-Type: image/gif; name="tdtqilgjhu.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tdtqilgjhu.gif"
Content-ID: 

----------yynbceeefnexpyuconyr
Content-Type: application/octet-stream; name="You_will_answer_to_me.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="You_will_answer_to_me.zip"

----------yynbceeefnexpyuconyr--

Date: Sat, 22 May 2004 15:59:07 +0530
To: "Ietf-pkix" <[email-masked]>
From: "Wpolk" <[email-masked]>
Subject: Forum notify
Sender: [email-masked]

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

<html><body>

<br>
</body></html>

----------uplrwiyrlmkhhkibqnpu
Content-Type: application/octet-stream; name="Information.vbs"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Information.vbs"

----------uplrwiyrlmkhhkibqnpu--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-07.txt
Date: Fri, 21 May 2004 15:55:36 -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 Operational 
			  Protocols: Certificate Store Access via HTTP
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-pkix-certstore-http-07.txt
	Pages		: 0
	Date		: 2004-5-21
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure (PKI). 
This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) 
as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI 
repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-certstore-http-07.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-certstore-http-07.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-certstore-http-07.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked], [email-masked], "Miguel Rodriguez" <[email-masked]>
Subject: Re: Signature in OCSP Request
From: "Frank Balluffi" <[email-masked]>
Date: Tue, 18 May 2004 08:23:07 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 004408FB85256E98_=
Content-Type: text/plain; charset="us-ascii"

Yasir,

As I recall, it is necessary to reverse the bytes of a signature generated 
by CAPI.

Frank

"Yasir Khan" <[email-masked]>
Sent by: [email-masked]
05/18/2004 06:07 AM

        To:     "Miguel Rodriguez" <[email-masked]>, <[email-masked]>
        cc:     <[email-masked]>
        Subject:        Re: Signature in OCSP Request

Hello 
 
 I have attached the TBSData.req  and signed requests after siging with 
CAPI and another toolkit. The file  toolkitSignedRequest.req is a signed 
request file that was signed with a toolkit  and OCSP responders accept 
the request. Wheras capiDirRequest.req is a file  in which signatures have 
been calculated from CAPI and attached to request. But  OCSP servers are 
unable to verify the signatures of the request. The last file 
capipkcsRequest.req is a request in which we made a PKCS#7 object of TBS 
Data  using CAPI and obtained the signatures from PKCS#7 and attached to 
request.
 
We are unable to contrust  a correct signed request using CAPI. The 
signatures in case of CAPI are  different but we dont know why they are 
different?
 
Any help will be highly  appreciated.
 
Regards 
----- Original Message ----- 
From:  Miguel  Rodriguez 
To: 'Yasir Khan' ; [email-masked] 
Sent: Tuesday, May 18, 2004 5:41 AM
Subject: RE: Signature in OCSP  Request

You  may need to reverse the signature so it can be verified by the OCSP 
server.  The signature should be computed over the tbsRequest structure. 
Regarding the  algorithms RFC 2560 is nto specific when it comes to signed 
requests, we need  further clarification of this point.
 
Miguel A Rodriguez
SeguriData
Mexico
-----Original Message-----
From: [email-masked]  [mailto:[email-masked]] On Behalf Of Yasir  Khan
Sent: Monday, May 17, 2004 9:01 AM
To:  [email-masked]
Cc: [email-masked]
Subject:  Signature in OCSP Request

Hello
 
I have a question about the signature field in OCSP request. What  exactly 
should it contain and what 
algorithms can be used for OCSP  request signing? 
 
When i create a signature using MS CAPI, OCSP reponders are unable to 
verify the signatures whereas we
can verify it using CAPI. What data do  we set in signature field exactly?
 
Regards,
 
Yasir

The following file(s) have been deleted by: Frank Balluffi on 5/18/2004 
8:20:52 AM

capiDirRequest.req
capipkcsRequest.req
TBSData.req
toolKitSignedRequest.req
smime.p7s
ATTOZ6J1
ATT0LW3D
ATTMN5LQ
ATTYKNMP
smime.p7s

--=_alternative 004408FB85256E98_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2><tt>Yasir,</tt></font>
<br>
<br><font size=2><tt>As I recall, it is necessary to reverse the bytes of a signature generated by CAPI.</tt></font>
<br>
<br><font size=2><tt>Frank</tt></font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Yasir Khan&quot; &lt;[email-masked]&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</font>
<p><font size=1 face="sans-serif">05/18/2004 06:07 AM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;Miguel Rodriguez&quot; &lt;[email-masked]&gt;, &lt;[email-masked]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;&lt;[email-masked]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: Signature in OCSP Request</font></table>
<br>
<br>
<br>
<br><font size=2>Hello </font>
<br><font size=3>&nbsp;</font>
<br><font size=2>&nbsp;I have attached the TBSData.req &nbsp;and signed requests after siging with CAPI and another toolkit. The file &nbsp;toolkitSignedRequest.req is a signed request file that was signed with a toolkit &nbsp;and OCSP responders accept the request. Wheras capiDirRequest.req&nbsp;is a file &nbsp;in which signatures have been calculated from CAPI and attached to request. But &nbsp;OCSP servers are unable to verify the signatures of the request. The last file &nbsp;capipkcsRequest.req is a request in which we made a PKCS#7 object of TBS Data &nbsp;using CAPI and obtained the signatures from PKCS#7 and attached to &nbsp;request.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2>We are unable to contrust &nbsp;a&nbsp;correct signed request using CAPI. The signatures in case of CAPI are &nbsp;different but we&nbsp;dont&nbsp;know why they are different?</font>
<br><font size=3>&nbsp;</font>
<br><font size=2>Any help will be highly &nbsp;appreciated.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2>Regards</font><font size=3>&nbsp;</font>
<br><font size=3>----- Original Message ----- </font>
<br><font size=3><b>From:</b> &nbsp;</font><a href=mailto:[email-masked]><font size=3 color=blue><u>Miguel &nbsp;Rodriguez</u></font></a><font size=3> </font>
<br><font size=3><b>To:</b> </font><a href=mailto:[email-masked]><font size=3 color=blue><u>'Yasir Khan'</u></font></a><font size=3> ; </font><a href="mailto:[email-masked]"><font size=3 color=blue><u>[email-masked]</u></font></a><font size=3> &nbsp;</font>
<br><font size=3><b>Sent:</b> Tuesday, May 18, 2004 5:41 AM</font>
<br><font size=3><b>Subject:</b> RE: Signature in OCSP &nbsp;Request</font>
<br>
<br><font size=2>You &nbsp;may need to reverse the signature so it can be verified by the OCSP server. &nbsp;The signature should be computed over the tbsRequest structure. Regarding the &nbsp;algorithms RFC 2560 is nto specific when it comes to signed requests, we need &nbsp;further clarification of this point.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2>Miguel A Rodriguez</font>
<br><font size=2>SeguriData</font>
<br><font size=2>Mexico</font>
<br><font size=2>-----Original Message-----</font>
<br><font size=2><b>From:</b> </font><a href="mailto:[email-masked]"><font size=2 color=blue><u>[email-masked]</u></font></a><font size=2> &nbsp;[mailto:[email-masked]] <b>On Behalf Of </b>Yasir &nbsp;Khan</font>
<br><font size=2><b>Sent:</b> Monday, May 17, 2004 9:01 AM</font>
<br><font size=2><b>To:</b> &nbsp;[email-masked]</font>
<br><font size=2><b>Cc:</b> [email-masked]</font>
<br><font size=2><b>Subject:</b> &nbsp;Signature in OCSP Request</font>
<br>
<br>
<br>
<br>
<br><font size=2>Hello</font>
<br><font size=2>&nbsp;</font>
<br><font size=2>I have a question about the signature field in OCSP request. What &nbsp;exactly should it contain and what </font>
<br><font size=2>algorithms can be used for OCSP &nbsp;request signing? </font>
<br><font size=2>&nbsp;</font>
<br><font size=2>When i create a signature using MS CAPI, OCSP reponders are unable to &nbsp;verify the signatures whereas we</font>
<br><font size=2>can verify it using CAPI. What data do &nbsp;we set in signature field exactly?</font>
<br><font size=2>&nbsp;</font>
<br><font size=2>Regards,</font>
<br><font size=2>&nbsp;</font>
<br><font size=2>Yasir</font>
<br><font size=2>&nbsp;</font>
<br><font size=3>&nbsp;</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">The following file(s) have been deleted by: Frank Balluffi on 5/18/2004 8:20:52 AM</font>
<br>
<br><font size=2 face="sans-serif">capiDirRequest.req</font>
<br><font size=2 face="sans-serif">capipkcsRequest.req</font>
<br><font size=2 face="sans-serif">TBSData.req</font>
<br><font size=2 face="sans-serif">toolKitSignedRequest.req</font>
<br><font size=2 face="sans-serif">smime.p7s</font>
<br><font size=2 face="sans-serif">ATTOZ6J1</font>
<br><font size=2 face="sans-serif">ATT0LW3D</font>
<br><font size=2 face="sans-serif">ATTMN5LQ</font>
<br><font size=2 face="sans-serif">ATTYKNMP</font>
<br><font size=2 face="sans-serif">smime.p7s</font>
<br>
<br>
<br>
--=_alternative 004408FB85256E98_=--

From: "Yasir Khan" <[email-masked]>
To: "Miguel Rodriguez" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Signature in OCSP Request
Date: Tue, 18 May 2004 15:07:53 +0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0086_01C43CE9.E957D2F0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_0087_01C43CE9.E957D2F0"

------=_NextPart_001_0087_01C43CE9.E957D2F0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_0088_01C43CE9.E957D2F0"

------=_NextPart_002_0088_01C43CE9.E957D2F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

MessageHello=20

 I have attached the TBSData.req and signed requests after siging with =
CAPI and another toolkit. The file toolkitSignedRequest.req is a signed =
request file that was signed with a toolkit and OCSP responders accept =
the request. Wheras capiDirRequest.req is a file in which signatures =
have been calculated from CAPI and attached to request. But OCSP servers =
are unable to verify the signatures of the request. The last file =
capipkcsRequest.req is a request in which we made a PKCS#7 object of TBS =
Data using CAPI and obtained the signatures from PKCS#7 and attached to =
request.

We are unable to contrust a correct signed request using CAPI. The =
signatures in case of CAPI are different but we dont know why they are =
different?

Any help will be highly appreciated.

Regards=20
  ----- Original Message -----=20
  From: Miguel Rodriguez=20
  To: 'Yasir Khan' ; [email-masked]=20
  Sent: Tuesday, May 18, 2004 5:41 AM
  Subject: RE: Signature in OCSP Request

  You may need to reverse the signature so it can be verified by the =
OCSP server. The signature should be computed over the tbsRequest =
structure. Regarding the algorithms RFC 2560 is nto specific when it =
comes to signed requests, we need further clarification of this point.

  Miguel A Rodriguez
  SeguriData
  Mexico
    -----Original Message-----
    From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Yasir Khan
    Sent: Monday, May 17, 2004 9:01 AM
    To: [email-masked]
    Cc: [email-masked]
    Subject: Signature in OCSP Request

    Hello

    I have a question about the signature field in OCSP request. What =
exactly should it contain and what=20
    algorithms can be used for OCSP request signing?=20

    When i create a signature using MS CAPI, OCSP reponders are unable =
to verify the signatures whereas we
    can verify it using CAPI. What data do we set in signature field =
exactly?

    Regards,

    Yasir

------=_NextPart_002_0088_01C43CE9.E957D2F0
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>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>Hello </FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>&nbsp;I have attached =
the TBSData.req=20
and signed requests after siging with CAPI and another toolkit. The file =

toolkitSignedRequest.req is a signed request file that was signed with a =
toolkit=20
and OCSP responders accept the request. Wheras =
capiDirRequest.req&nbsp;is a file=20
in which signatures have been calculated from CAPI and attached to =
request. But=20
OCSP servers are unable to verify the signatures of the request. The =
last file=20
capipkcsRequest.req is a request in which we made a PKCS#7 object of TBS =
Data=20
using CAPI and obtained the signatures from PKCS#7 and attached to=20
request.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>We are unable to =
contrust=20
a&nbsp;correct signed request using CAPI. The signatures in case of CAPI =
are=20
different but we&nbsp;dont&nbsp;know why they are =
different?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>Any help will be highly =

appreciated.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 =
size=3D2>Regards</FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #800080 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]">Miguel=20
  Rodriguez</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">'Yasir Khan'</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, May 18, 2004 =
5:41 AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Signature in OCSP=20
  Request</DIV>
  <DIV><BR></DIV>
  <DIV><SPAN class=3D610453200-18052004><FONT face=3DArial =
color=3D#0000ff size=3D2>You=20
  may need to reverse the signature so it can be verified by the OCSP =
server.=20
  The signature should be computed over the tbsRequest structure. =
Regarding the=20
  algorithms RFC 2560 is nto specific when it comes to signed requests, =
we need=20
  further clarification of this point.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D610453200-18052004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D610453200-18052004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Miguel A Rodriguez</FONT></SPAN></DIV>
  <DIV><SPAN class=3D610453200-18052004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>SeguriData</FONT></SPAN></DIV>
  <DIV><SPAN class=3D610453200-18052004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Mexico</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> <A =

    =
href=3D"mailto:[email-masked]">[email-masked]=
</A>=20
    [mailto:[email-masked]] <B>On Behalf Of </B>Yasir=20
    Khan<BR><B>Sent:</B> Monday, May 17, 2004 9:01 AM<BR><B>To:</B>=20
    [email-masked]<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B>=20
    Signature in OCSP Request<BR><BR></FONT></DIV><FONT face=3DArial =
color=3D#800080=20
    size=3D2>
    <DIV><BR>Hello</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>I have a question about the signature field in OCSP request. =
What=20
    exactly should it contain and what <BR>algorithms can be used for =
OCSP=20
    request signing? </DIV>
    <DIV>&nbsp;</DIV>
    <DIV>When i create a signature using MS CAPI, OCSP reponders are =
unable to=20
    verify the signatures whereas we<BR>can verify it using CAPI. What =
data do=20
    we set in signature field exactly?</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>Regards,</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>Yasir</DIV>
    <DIV>&nbsp;</DIV>
    <DIV></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_002_0088_01C43CE9.E957D2F0--

------=_NextPart_001_0087_01C43CE9.E957D2F0
Content-Type: application/octet-stream;
	name="capiDirRequest.req"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="capiDirRequest.req"

------=_NextPart_001_0087_01C43CE9.E957D2F0
Content-Type: application/octet-stream;
	name="capipkcsRequest.req"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="capipkcsRequest.req"

------=_NextPart_001_0087_01C43CE9.E957D2F0
Content-Type: application/octet-stream;
	name="TBSData.req"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="TBSData.req"

MIIBUaADAgEAoVakVDBSMQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExDzANBgNVBAsT
BlBlb3BsZTEfMB0GA1UEAxMWVGVzdCBBbGljZSBUZXN0IEwyIENBMTCBvjCBuzA6MAkGBSsOAwIa
BQAEFMszD4wKRj36Og+QCJqGp1fwPTmxBBTMDfmwJSAJOapLfc1q85EJxd/8wAIBBaB9MHsweQYJ
KwYBBQUHMAEHBGwwajBEMQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExDDAKBgNVBAsT
A1NRQTEUMBIGA1UEAxMLVGVzdCBMMiBDQTEwIjAgBggrBgEFBQcwAYYUaHR0cDovL2FzY2VydGlh
LTU6ODWiMTAvMBoGCSsGAQUFBzABBAQNMAsGCSsGAQUFBzABATARBgkrBgEFBQcwAQIEBNR7wTI=

------=_NextPart_001_0087_01C43CE9.E957D2F0
Content-Type: application/octet-stream;
	name="toolKitSignedRequest.req"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="toolKitSignedRequest.req"

------=_NextPart_001_0087_01C43CE9.E957D2F0--

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

------=_NextPart_000_0086_01C43CE9.E957D2F0--

From: "Miguel Rodriguez" <[email-masked]>
To: "'Yasir Khan'" <[email-masked]>, <[email-masked]>
Subject: RE: Signature in OCSP Request
Date: Mon, 17 May 2004 19:41:14 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

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

You may need to reverse the signature so it can be verified by the OCSP
server. The signature should be computed over the tbsRequest structure.
Regarding the algorithms RFC 2560 is nto specific when it comes to
signed requests, we need further clarification of this point.
 
Miguel A Rodriguez
SeguriData
Mexico

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Yasir Khan
Sent: Monday, May 17, 2004 9:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: Signature in OCSP Request

Hello
 
I have a question about the signature field in OCSP request. What
exactly should it contain and what 
algorithms can be used for OCSP request signing? 
 
When i create a signature using MS CAPI, OCSP reponders are unable to
verify the signatures whereas we
can verify it using CAPI. What data do we set in signature field
exactly?
 
Regards,
 
Yasir

------=_NextPart_000_0027_01C43C46.F4E3E5D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D610453200-18052004><FONT face=3DArial color=3D#0000ff =
size=3D2>You=20
may need to reverse the signature so it can be verified by the OCSP =
server. The=20
signature should be computed over the tbsRequest structure. Regarding =
the=20
algorithms RFC 2560 is nto specific when it comes to signed requests, we =
need=20
further clarification of this point.</FONT></SPAN></DIV>
<DIV><SPAN class=3D610453200-18052004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D610453200-18052004><FONT face=3DArial color=3D#0000ff =
size=3D2>Miguel=20
A Rodriguez</FONT></SPAN></DIV>
<DIV><SPAN class=3D610453200-18052004><FONT face=3DArial color=3D#0000ff =

size=3D2>SeguriData</FONT></SPAN></DIV>
<DIV><SPAN class=3D610453200-18052004><FONT face=3DArial color=3D#0000ff =

size=3D2>Mexico</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Yasir Khan<BR><B>Sent:</B> Monday, May 17, 2004 9:01=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> Signature in OCSP=20
  Request<BR><BR></FONT></DIV><FONT face=3DArial color=3D#800080 =
size=3D2>
  <DIV><BR>Hello</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>I have a question about the signature field in OCSP request. What =
exactly=20
  should it contain and what <BR>algorithms can be used for OCSP request =

  signing? </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>When i create a signature using MS CAPI, OCSP reponders are =
unable to=20
  verify the signatures whereas we<BR>can verify it using CAPI. What =
data do we=20
  set in signature field exactly?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Regards,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Yasir</DIV>
  <DIV>&nbsp;</DIV>
  <DIV></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0027_01C43C46.F4E3E5D0--

From: The IESG <[email-masked]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, pkix mailing list <[email-masked]>, pkix chair <[email-masked]>, pkix chair <[email-masked]>
Subject: Document Action: 'A 224-bit One-way Hash Function: SHA-224'  to Informational RFC 
Date: Mon, 17 May 2004 15:59:30 -0400
Sender: [email-masked]

The IESG has approved the following document:

- 'A 224-bit One-way Hash Function: SHA-224 '
   <draft-ietf-pkix-sha224-01.txt> as an Informational RFC

This document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact persons are Steve Bellovin and Russ Housley.

Technical Summary
 
 This draft specifies a 224-bit cryptographic hash function.  224 bits is
 the obvious choice to match triple-DES in strength against brute-force
 attacks. At least two independent implementations exist and agree on the
 test vectors in this document.

Working Group Summary
 
 Since NIST has already specified SHA-224, this was the only reasonable
 choice.

Protocol Quality
 
 Steve Bellovin has reviewed this document for the IESG.

RFC Editor Note

 Please make two changes.

 1. Please correct typos in the Abstract.

    OLD:

     ... A SHA-224 is based on SHA-256, but it uses an different ...

    NEW:

     ... SHA-224 is based on SHA-256, but it uses a different ...

 2. The Introduction has two paragraphs.  Please add an additional
    paragraph at the end of the Introduction.

    NEW:

     This document makes the SHA-224 one-way hash function specification
     available to the Internet community, and it publishes the object
     identifiers for use in ASN.1-based protocols.

From: "Peter Hesse" <[email-masked]>
To: "'PKIX List'" <[email-masked]>
Cc: "'Steve Hanna'" <[email-masked]>
Subject: RE: Comments on Path Building I-D
Date: Mon, 17 May 2004 16:41:10 -0400
Sender: [email-masked]

Steve,

<resending because I exceeded the PKIX list size limit...>

Thank you for your in-depth reading of the document and the large number of
comments.  I will attempt to address the majority of them in this message.
I apologize for the time it has taken me to respond.

> Overall Comments:
> 
> * My main overall comment is the one I made last July. There 
> is not consensus on path building techniques in the PKIX 
> working group or the IETF. Why? Because we don't understand 
> the problem thoroughly yet.

We do understand the problem.  The problem is a traditional graph theory
problem.  The only new part of the problem as it relates to PKI is how to
define the penalty function.  We have defined heuristics that make sense for
PKI.

I'm not sure that this is a reason to prevent this document from
progressing.  This document is based upon the best research we have to date,
which includes real-world experience with operational PKIs and users.  If at
a later time, there is additional research performed, and new conclusions
are reached, then the obvious recommendation would be to update the draft.
Until that time, I do not think it is useful to withhold this document.
 
> In this document, you advocate depth first search and suggest 
> that building forward is usually best. I don't think you have 
> carefully considered a wide variety of other algorithms like 
> breadth first search, meet in the middle, etc. Can you show 
> me any solid evidence that shows your algorithms are better 
> than the alternatives?

Yes and no.  I can generate a set of PKI structures which will make this
algorithm work best, just as you could generate a set of PKI structure which
would make another algorithm work best.  Until there are useful real-world
examples to test against which demonstrates one approach is generally better
than another, such evidence would be questionable.  The methods described in
the draft have been used in real-world PKIs with success.
 
> I doubt that you have any such proof. In fact, it seems clear 
> to me that depth first search is a poor algorithm for 
> building cert paths. I say this as a person who has 
> implemented that algorithm myself and regretted it. The 
> problem is that if you make a wrong choice, you must 
> completely explore that part of the PKI before you consider 
> backing out and trying other options. I have heard stories of 
> path building taking 35 minutes or more when there was a 
> valid short path because the builder used DFS and headed down 
> the wrong path.

Certainly these are horror stories, and if the path-building software
consistently took 35 minutes to develop a path, it would not be in use
today.  In the document, we advocate finding a valid path fastest to prevent
such a thing from occurring.  

There may be ways to optimize building so that a valid path is even more
likely found first across a wider range of conditions than the approach we
described.  However, this is a balancing act between complexity for
implementers, performance, and functionality.  We may be able to design an
exceedingly complex (to implement) algorithm that almost always yields best
performance and allows for every conceivable scenario, but no one would want
to (or be able to) implement it.

> We need to do our homework before making any solid 
> recommendations to implementers. I suppose it's better to 
> have some advice than none, but this document should have a 
> prominent warning that these techniques are experimental. In 
> fact, we might want to give the RFC Experimental status.

We (as authors) have influence but no control as to whether the document
heads down standards, informational, or experimental tracks.  We have
requested informational status, but the IESG can decide whatever they wish.
I truly feel that this document is Informational, it provides potential
implementers with information that they can use when they are creating their
own implementation; it provides little in the way of strict recommendations.
Note the following snippets of RFC2026:

4.2.1  Experimental

   The "Experimental" designation typically denotes a 
   specification that is part of some research or development 
   effort. [...]

4.2.2  Informational

   An "Informational" specification is published for the 
   general information of the Internet community, and does not
   represent an Internet community consensus or recommendation.
   [...]

> As I've suggested before, I want to see a careful analysis of 
> different path building strategies. Theoretical analysis will 
> probably be useful, but I expect it will also be useful to 
> compare real-world performance with a variety of topologies 
> (some from real-world deployments, some looking at possible 
> futures like many cross-certified bridges). We need to try 
> out a lot of ideas without getting committed to any too 
> early. The cert path building panel at the PKI R&D Workshop 
> this year was a good start, but we need to do more in-depth 
> work. I've started talking to some other researchers about 
> this. I hope that this documents' authors will join this effort.
> Their experience and aid will be valuable.

I agree with you and would also like to see additional research and analysis
performed in this area.  However, X.509 has existed in one form or another
since 1988 and there has never been any guidance for implementers on how to
build certification paths.  Now, 16 years later, we are offering to provide
a document with some guidance--a starting point at the least--for
implementers.  We should not wait any longer for additional research.

When new research brings something additional to light, this RFC can be
updated or replaced as warranted.
 
> * At several places in the document, you refer to the "authors'
> opinions". If this was truly a working group document, it 
> would reflect the consensus of the working group, not the 
> opinions of the authors. As I said before, I don't see 
> working group consensus on this topic. Has anyone other than 
> me (and maybe the authors) carefully reviewed the current 
> draft? I haven't seen any comments on it during Last Call.

We did receive a significant number of comments from some other folks on
earlier drafts, and we have addressed those comments.  This document must be
based upon the opinions of the authors, because as I mentioned above, one
can always create a path which makes a particular algorithm operate well.
As the section from RFC2026 above, there is no problem with an informational
RFC where the judgment calls in the document are based upon the opinions of
the authors.

> Since this document does not reflect working group consensus, 
> I do not think it should go forward as a working group draft. 
> It should be an individual submission. But I suppose once it 
> becomes an RFC nobody will ever know whether it was a working 
> group submission or not. And I really do think it's useful to 
> have some guidance on cert path building (even if we don't 
> understand the problem very well). So I'd be OK with having 
> it be a working group submission if it goes to Experimental 
> status and a caveat is added at the beginning warning that 
> this is only the authors' opinion (albeit an educated 
> opinion) and that further study is under way to determine 
> which techniques are actually preferred.

As I mentioned earlier, based upon RFC2026, I don't think that experimental
status is appropriate.  As far as a caveat at the beginning of the document,
we intended to have already performed that in section 1.2, Purpose:
  
# This document provides information and guidance for certification
# path building.  There are no requirements or protocol
# specifications in this document.  This document provides many
# options for performing certification path building, as opposed to
# one particular way to best perform certification path building.
# This document draws upon the authors' experience with existing
# complex certification paths to offer insights and recommendations
# to developers integrating support for [X.509] digital
# certificates into their applications.
#  
# In addition, this document suggests using an effective general
# approach to path building that involves a depth first tree
# traversal.  While the authors believe this approach offers the
# balance of simplicity in design with very effective and
# infrastructure neutral path building capabilities, the algorithm
# is no more than a suggested approach. Other approaches (e.g.,
# building complete spanning trees of the PKI.) exist and may be
# shown to be more effective under certain conditions.
# Certification path validation is described in detail in
# both [X.509] and [RFC 3280] and is not repeated in this document. 

> * You should include in this document a section with guidance 
> to PKI designers about what they can do to make path building 
> easier. Here are some ideas:
> 
> Use a simple topology (hierarchical with one root), when possible.
> Include AIA, SIA, and CRLDP extensions in certificates. Make 
> certificates (especially CA certificates) and CRLs easily 
> available by LDAP and HTTP, populating both sides of the 
> crossCertificatePair attribute. Use name constraints and 
> policy constraints whenever possible, especially at high 
> fanout points like bridges. Avoid having more than two high 
> fanout CAs (at most) between any two points, if possible.

I don't disagree with any of these suggestions, and I think that they are
appropriate for capture in a document.  I'm just not sure that this document
is the right place.  This is less of a path development issue and more of a
PKI architecture issue.  Therefore, I recommend that a separate document be
created to provide guidance to PKI implementers on how best to construct
their PKI so that path development routines have a good chance for success.
I would be happy to collaborate with you on such a document.

> * I have a *serious* objection to the idea that someone is 
> going to specially configure path building software for a 
> particular PKI environment (as I think you imply at the end 
> of section 2.3, early in section 3.4, and in a few other 
> places). This is not practical. Most organizations do not 
> have a PKI wizard on staff (especially a path building 
> wizard). The path building software must just work, 
> automatically. If we can't do that, PKI will never be widely 
> used (at least, not in a non-hierarchical topology). 
> Fortunately, I see no reason why we need special 
> configuration. With AIA and SIA and CRLDP and some good 
> algorithms, we should be able to build paths just fine in 
> almost any PKI without any configuration.

Again, I agree with what you have written here.  However, my practical
experience in this area is a reason for this implication being made.  With
no guidance, a path building implementer might be just concerned with
getting their software to work with the particular PKI they have been faced
with in testing.  This occurred a few times in early revs of the DoD PKI and
government-funded software.

Our goal as stated in the purpose section is an approach which "offers the
balance of simplicity in design with very effective and infrastructure
neutral path building capabilities."  Certainly a design can be simplified
if parts of the implementation are left out, because they will never be used
in the target infrastructure.  The end of our section 2.1 lists the reasons
why users might want to do this.  Additionally, as I mentioned above, one
can always come up with an algorithm that works best in their specific
environment.  While it may not be practical to expect, if there is enough
pressure to ensure that paths are built and validated in a timely fashion, I
can imagine it happening.

Oh, and two additional notes: CRLDP does not help in path development--just
for retrieving data needed for the path.  And, AIA does not help path
development any better than a populated LDAP directory does.  (If a issuer
has multiple certificates, either AIA will be underpopulated or you will
face the same dilemma in terms of which certificate to use to develop the
path.)

> Substantive Comments:
> 
> * Section 1.2 (Purpose) says "... this document suggests using ...
> depth first tree traversal. ... Other approaches (e.g., 
> building complete spanning trees of the PKI.) exist and may 
> be shown to be more effective under certain conditions."
> 
> Building a complete spanning tree of the PKI is not a decent solution.
> Please change this to something more reasonable, like breadth 
> first search. Otherwise, you're just setting up a straw man, 
> an impractical alternative.

We will change this to a breadth first search.  Of course as we mention in
the document, in certain cases, this might be impractical as well.  (i.e.
forward cross-certificates not being present)

> * In section 1.4.1, you mention one disadvantage of the trust 
> list approach. You might want to mention the problem that 
> compromise of any trusted certificate compromises the entire system.

We will add this.

> * In section 1.4.2, you say that a partial mesh is a mixture 
> of unidirectional and bidirectional cross-certifications. 
> It's probably also important to note that in a partial mesh 
> there may be CAs that are not directly cross-certified at all.

We will add this.

> * What is a Root CA doing in Figure 3? As you say, each EE in 
> a mesh usually trusts the CA that issued its certificate. 
> Because of this Root CA, Figure 3 does not depict a full 
> mesh, as stated in 1.4.2. I suggest that you remove the Root CA.

This was changed to be a root based upon a comment made by Denis Pinkas
stating that the diagrams were inconsistent.  I think I agree with you, it
is more confusing with the root in there.  We will change this.
 
> * At the end of section 1.4.3, you raise the concern that the 
> assurance of a high-assurance PKI may be diluted by 
> cross-certifying with a less restrictive PKI. If you're going 
> to raise this concern, you should mention that it can be 
> addressed through the use of certificate policies.

We will add this.

> * At the end of section 1.4.4, you say that connecting PKIs 
> with a bridge results in a non-hierarchical PKI. Certainly, 
> this is true. But mesh and hybrid PKIs are not hierarchical 
> either. Why raise this here?

This is mentioned because a lot of people look at a picture involving a
Bridge, and think of the Bridge as a root, and everything being subordinate
to it.  This is just another attempt to prevent that.

> And the following sentence which states that any PKI can be 
> considered hierarchical from the right perspective only 
> applies if you remove and duplicate links in the PKI. Since 
> you don't have space to get into this here, I suggest you 
> remove those last two sentences.

We already reference section 2.3 where we go into some more detail.

> * At the end of the first paragraph of section 2.1, you 
> explain that S/MIME messages commonly include certificates. I 
> think you would be wise to also mention SSL/TLS since this is 
> the most widespread use of PKI and it also supplies 
> certificates in the protocol.

We will add this.

> * Before Figure 6, you explain how certificates are depicted 
> with arrows in your figures. You should also explain the 
> "B(A)" notation you use.

We will add an explanation to this section.

> * At the end of the paragraph after Figure 6, you say that 
> building paths is as important as validating them. I don't 
> agree. Many products have been shipping for years and work 
> just fine without building. In a complex PKI, building is 
> important. But in a simple hierarchical PKI, it's not.

Even in a simple hierarchical PKI, some amount of building has occurred.
(OK, maybe not in a REAL simple example with one trust root and all target
certificates issued directly by it...)  Building is important.  If you don't
build a path, you can't validate a path.  It's just that building in certain
cases is so easy it doesn't even seem like you're doing any work.

> * At the end of section 2.1, you have a large discussion of 
> why you believe building forward is usually better. This 
> duplicates later discussions on this topic. I suggest you 
> save this for later.

We will shorten section 2.1 and provide a cross-reference to the end of 2.3
where we discuss this in more detail.

> * In section 2.2, you could simplify and clarify Criterion 1 
> by changing it from this:
> 
>  Criterion 1: The implementation is able to find all possible paths.
> By this, it is meant that all possible certification paths 
> between the trust anchor and the target certificate which may 
> be valid paths can be built by the algorithm.
> 
> to this:
> 
>  Criterion 1: The implementation is able to find all possible paths.
> By this, it is meant that all valid certification paths 
> between  the trust anchor and the target certificate can be 
> built by the algorithm.

Yes, but I will propose changing it to (potentially) valid because I do not
necessarily want to burden path building software with having to also be
path validation software.  By potentially, I mean it is valid as far as the
builder can tell.  To some builders that is fully valid.  To others it may
still require a final sanity check/run through the validation procedure.
 
> * In section 2.2, Criterion 2 seems rather odd. Who cares 
> which invalid paths you build first? The important thing is 
> how quickly and efficiently you can build a valid path or 
> determine that no valid path exists.

The purpose of this criterion is ensure that the users get meaningful
errors.  You want to build paths which are likely to be valid before you go
off and build paths which have a very low chance of success.  What is a
better error for a user to see, "name constraints violation at certificate
14" or "cert 3 revoked"?  We will try and word this a bit better to get that
point across.

> * In section 2.3, you say that because certificates are not 
> permitted to repeat, every potentially valid path has a 
> terminus. But every potentially valid path *always* has a 
> terminus, even if certificates are allowed to repeat. As 
> defined in RFC 3280, a certification path is a collection of 
> n certificates. Every path has a finite number of 
> certificates. I suggest you remove the sentence "As a result, 
> every potential valid path has a terminus, a leaf on the tree."

Each path does have a terminus, once it becomes a path.  If certificates can
be repeated, the number of certificates in the path and the number of
possible paths both increase to infinity.  This is a wordsmithing issue that
may be able to be worded more clearly.  Perhaps we will change it to say "If
certificates could be repeated, loops can be formed such that the number of
paths and the number of certificates in a path both increase without bound
(e.g. A issues to B, B issues to C, and C issues to A.)"

> * In the following paragraph, you say that removing and 
> duplicating nodes and links in a PKI to turn it into a 
> hierarchy greatly simplifies software design. This may be so, 
> but it also removes many opportunities for insight and 
> optimization. For example, it increases the number of nodes 
> in the data structure and makes it harder to mark a certain 
> area of the PKI as unproductive (since that area may appear 
> several places in the tree).

We will remove "- this greatly simplifies software design." from the
sentence.

> * Later in that paragraph, you use the phrase "decision tree" 
> without defining it. I suggest that you define it in section 1.3.

We will add a definition for "decision tree".

> * One paragraph on page 16 (starting with "A more complicated
> example") talks about problems with building in the reverse 
> direction when there are many trust anchors. The real issue 
> here is fanout.
> Whether you're building forward or building reverse, it's bad 
> news when you get to a point where you have several choices. 
> It's especially bad if your heuristics (ranking) don't give 
> you much help in deciding which way to go. And it's even 
> worse if you're using depth-first search, since one wrong 
> move can send you off in the wrong direction for hours. 
> That's why I suggest breadth first search or (even better) 
> ranking all candidates at all points in the tree at each 
> decision time.
> 
> Four trust anchors is a four-way fanout. A similar situation 
> would arise if you were building forward and arrived at a CA 
> that has four certificates with it as the subject. In either 
> case, you hope that your ranking will help choose the right 
> path. And if you're using depth first search, you really hope 
> that you don't take a wrong turn.
> One technique for dealing with extreme fanout with fairly 
> equal rankings is to start building from the other end. 
> Another is to rank the certs at the fanout point low and try 
> another branch. A third is to use DPD to get help. And a 
> fourth is to tell PKI designers to use name constraints and 
> other techniques at high fanout points (like
> bridges) to help path building succeed.
> 
> I hope that you find this analysis useful.

I agree that this example may go into a little too much detail without
providing much benefit to the reader--we've done a good job of identifying
the problem but not at clearly identifying a solution.  I will try and
simplify the example, identify that the real enemy here is fanout, and that
to combat it, implementers should strive to use optimizations such as those
discussed in section 3.1 when there are a lot of choices at a particular
point of development. (By the way, this is p18 on my copy.)  

> * In Figure 10, are W, X, Y, and Z all trust anchors? I think so.
> That's pretty odd. Why would a relying party have all four of 
> those trust anchors? Who needs the bridge CA in that case? I 
> suspect that this topology was created to support your 
> arguments that repeating a (name, key) pair is bad and that 
> building in reverse is bad. If so, I think you can do better.

They are trust anchors for different relying parties, the trust anchors of
each of the PKIs which are cross-certified with the Bridge.  We will attempt
to make that clearer in the example.  In our example we are treating only W
as our trust anchor.

> Let's do a careful theoretical analysis and try out different 
> algorithms on different topologies. I suspect you're right 
> that repeating a (name, key) pair is bad but we need to think 
> about this carefully since it is a significant change to RFC 
> 3280. I think you will see below that building in reverse is 
> a useful tool that should be used in conjunction with 
> building forward. But we need to show the merits of our 
> approaches through analysis, not by consructing topologies 
> that serve our own purposes.

We have identified reasons why a (name, key) pair should not be repeated
within this document, and why building implementations should consider not
allowing them in section 2.4.2.  We have not attempted to change RFC3280
although I think we would have a decent argument for this, it is for a
different time and place.  

> * In the paragraph after Figure 10, you have several 
> sentences explaining the diagram's notation. This was 
> explained much earlier.
> The rest of the paragraph (explaining where certificates 
> would be stored in an LDAP directory) also duplicates 
> material found elsewhere.
> I suggest that you remove these, since the document is 
> already too long.

We will remove the duplication.
 
> * In section 2.4.2, you seem to be proposing that software 
> should build a decision tree. I believe you don't intend for 
> the software to actually build a tree for the entire PKI but 
> only to move incrementally through the PKI adding nodes and 
> links to the tree as needed. I hope that's the case, anyway. 
> Otherwise, you'd need to download all certs in the PKI! If 
> I'm right, you need to be much clearer about this. I could 
> easily imagine a developer writing code that actually builds 
> the tree. That code would work fine in a small test PKI but 
> flood the directory with requests and then die in a large PKI.

We will try and make this clearer.

> * After Figure 11, you point out that building in reverse is 
> not good in this case. Sure. The EE is in a simple hierarchy. 
> Of course, building forward is best there. If you don't know 
> the topology (especially if you have several trust anchors), 
> starting with forward is fine. Then you can switch or meet in 
> the middle if things get hairy.

As I mentioned before, one can always make an example that is good for a
particular argument!  In this case though, we don't say it is not good, we
say it is not possible, due to a lack of available certificates.
 
> * In section 2.6, you say "[...] the path builder only needs 
> to store the current location in the tree [...] All completed 
> branches can be discarded from memory [...]". Maybe. There's 
> a lot to be said for retaining records of paths you have 
> already tried and rejected. Then you can avoid retrying them 
> at a different point in the graph (unless conditions are 
> sufficiently different to merit a retry).

I agree with what you've written.  We have even some implementations that
mark a path as bad given a certain set of inputs so that it is not tried
again.  We will reword this section.

> * Later in section 2.6, you say "Consider HTTPS support" for 
> CRLDP and AIA. Why would this be valuable? You're retrieving 
> signed data. Using HTTPS may trigger another path build, 
> maybe even a loop where one build triggers another which 
> triggers another and so on. I suppose some repositories may 
> require HTTPS to authenticate the client or protect the certs 
> from prying eyes. But you should probably warn that doing so 
> may be expensive and that implementers should protect against loops.

I think we know of someone that is using HTTPS for one of these cases, and
that is why it was thrown in there.  We will add something to warn users
that HTTPS support needs to be considered in terms of its potential impact
creating a loop.

> * Toward the end of section 2.6, you talk about the path 
> cache. You call for "a configurable expiration date for each 
> entry". Who would configure the date and why? I'm a path 
> building geek and I can't imagine configuring such a thing!

By configurable, I think it is meant that the software would set the
expiration when it creates the entry, based upon a number of factors.
Examples of factors include the expiry of the information used to make the
determination, bandwidth, assurance level, storage space, whether it is a
server or client, etc.  We will make this clearer.

> * A few sentences later, you suggest storing issuer-subject 
> cert relationships. If you want to do this, I suggest that 
> you use a cert hash instead of an (issuer, serial) tuple. 
> Issuer, serial is *not* always unique, especially across 
> multiple PKIs or when one CA is malicious (and remember that 
> some CAs are only partly trusted in a modern PKI).

According to X.509, Issuer, Serial is always unique, since a given issuer
cannot repeat a serial number.  Of course, this assumes a "global directory"
where issuers are never repeated.  Issuer/Serial tuple is used as the
certificate identifier in a number of protocols (S/MIME for example) and of
course it is important for users to ensure that the resultant path is valid
through validation of signatures.

> * In section 2.7.1, you talk about the required inputs. 
> Instead of supplying the actual Target Certificate, it is 
> sometimes useful to provide criteria that describe what sorts 
> of target certificates you're willing to accept. For 
> instance, when doing S/MIME encryption to a new correspondent 
> you may not have the correspondent's encryption certificate. 
> The path building software can help find it if you tell it 
> what you need.

We will note this as a possibility.  Our goal for this document was "given a
certificate, how do I build its path" but we will note this.

> * In section 3.2, you recommend that path building software 
> output a detailed log. I think you should recommend that this 
> log be carefully structured so that the paths tried can be 
> easily reconstructed by a diagnostic program. My team built a 
> tool that shows the cert graph and then replays the paths our 
> builder tried, lighting up each one in sequence. We found 
> this a great help in understanding the behavior of our 
> software (finding bugs, improving algorithms, etc.). It's 
> also a very cool way to demo path building, which otherwise 
> is a pretty boring demo ("see, there's the web page!").

Heh.  Mark that up as a good reason to work in R&D.  We will make this
recommendation.  (About the reconstruction of the paths, not necessarily the
lighting-up part.)

> * Later in that paragraph, you say "Ideally, there would be a 
> mechanism for turning this logging on and off [...]". I'd 
> change this to "There should be [...]". Logging is expensive 
> (in storage and CPU time), especially for path building where 
> you commonly try hundreds of certificates or more to create a 
> valid path. You really need a way to turn logging off and on.

We also can't be prescriptive since this is an Informational document... I
agree but I will not use the word "should".

> * A few paragraphs later, you say "it may be useful to not 
> rule out any paths" and just return each path as its built, 
> even if it's invalid. The problem with this is that 
> (especially with a depth first
> search) is that there are many topologies that may cause you 
> to wander among many invalid paths. Why is this technique 
> good? You say it will "provid[e] a more rapid response to the 
> caller than one which builds all possible paths." Maybe. I 
> suspect you'll instead waste time by spending a lot of time 
> returning invalid paths to the caller. I don't see much 
> reason to return invalid paths except in a diagnostic log or 
> for your interesting idea of providing one path that's 
> *mostly* valid for debugging and in case the caller finds 
> that invalid path educational or compelling.

Of course the simplest case of this is you build a path and everything lines
up except a certificate along the way is expired or revoked.  In this case,
the path is probably the "right" one and is not valid, and won't be.  This
is what we're getting at.

> * A few paragraphs later, you lay out your approach. Here are 
> some comments on it:
> 
> You say "Do not check revocation status if it requires a 
> directory lookup or network access." Why not start the 
> revocation check and let it run in parallel while you do 
> other things (like checking certs deeper in the graph)? That 
> way, you'll have the revocation check done when you need it. 
> And if the check fails you can abort all work that was based 
> on the validity of that certificate. Of course, you'll want 
> to cache the revocation status of certificates for some time.

Again, this gets back to keeping it simple for the implementer.  See later,
we will add to section 7 some more advanced optimizations that includes
background/parallel processing.
 
> You say "Do not check digital signatures". Again, why not run 
> this in parallel? Most of path building time (about 90%, 
> based on our data) is spent waiting for the network (while 
> downloading certificates and such). That's an ideal time to 
> be checking signatures. And, of course, you'll want to cache 
> the results of signature checks.

Same as above.  Signature checks are computationally expensive.  For
3280-compliant certificates, AKID/SKID matching is a much less expensive way
to know that the signatures are likely to chain.
 
> You say "Do not check anything that can not be checked as 
> part of the iterative process of traversing the tree." Why 
> not? I expect you would want to run these final checks (like 
> full policy processing when building forward) before 
> returning the path to the caller. Otherwise, the caller will 
> need to run a complete validation of the path, which will 
> take much more time than just running these last few checks.

I'm not entirely sure I understand what you're saying here.  We're
recommending you don't check anything that's going to get checked anyway.
 
> * In the last paragraph of 3.2, you say "Second, it is fairly 
> uncommon in typical application environments to encounter a 
> revoked key; therefore, most certificates validated will not 
> be revoked." In a PKI, we don't revoke a key. We revoke a 
> certificate. Therefore, this sentence should read "Second, it 
> is fairly uncommon in typical application environments to 
> encounter a revoked certificate."

Agree.  We will make this change.
 
> * Why include section 3.3 at all? It's very odd to have an 
> IETF spec talking about internal data structures. Maybe you 
> should just give everyone a copy of your code (since it is 
> apparently ideal) and save them the trouble of implementing 
> it! I'm going to skip my more detailed comments on this 
> section since I think it should be entirely removed.

I have no problem removing the data formats,  I think it is useful to have a
semi-pseudocode example worked through for implementers to read, so I don't
think we should remove the entire section.
 
> * In section 3.4, you refer say "developers should evaluate 
> each method with respect to the environment that the 
> application will operate, and assign weights to each 
> accordingly in the path building software.". First, the word 
> "that" in this sentence should be "in which". Second, this is 
> a prime example of the awful idea that developers must 
> examine each PKI and configure their software to run optimally there.

We will change to "in which".  Again, if efficiency is your number one
concern, it may be worthwhile to tune the path builder for your environment.
An example of a situation that deserves tuning is a server-based
implementation, when it is always processing paths for a particular
infrastructure.  

We have typically implemented the scoring weights to be read from
configuration files so that they can be tuned; default values would be used
in absence of tuned numbers.
 
> * In section 3.5.1, you say "According to [RFC 3280], 
> basicConstraints is required to be present with cA=TRUE in 
> all CA certificates."
> Actually, section 6.1.4 (k) of RFC 3280 says "Verify that the 
> certificate is a CA certificate (as specified in a 
> basicConstraints extension or as verified out-of-band)." 
> Maybe your software doesn't make any provision for 
> out-of-band indication of CA certificates, but you should 
> probably at least note the possibility that other software may do so.

We will change this to identify this rule must account for out-of-band
indications.
 
> * In section 3.5.5, you say "Certificates in the path cache 
> have been validated previously. There is some probability 
> that the path from that certificate to a trust anchor is 
> still valid." The path may still be valid but it may contain 
> constraints that are inconsistent with the path from the 
> Target Certificate to this certificate. You should probably 
> note that possibility.

We will add an additional note about the changes to initial constraints.

> * In section 3.5.6, you say that the Previously Verified 
> Signatures sorting method doesn't apply when building in 
> reverse. Actually, it does. Your analysis is incorrect. This 
> method never tells you which way the Target or Trust Anchor 
> is (which certificate is most likely).
> It only lets you rule out certificates because the signature 
> check would certainly fail.

I agree that this does help and will be included.

> * In section 3.5.7, you say the Path Length Constraints 
> sorting method "may be applied in reverse, but the benefit is 
> likely less than that of the forward direction". Why? You can 
> argue that the method is more effective when building in 
> reverse because path length constraints often appear close to 
> trust anchors.

Like you mention above, the forward direction lets you immediately rule out
a branch of certificates that would fail.  In the reverse direction, you
rule out branches farther down with some unknown fanout.   That said, I
think this section reads too opinionated and will change it appropriately.

> * In section 3.5.8, you say "Certificates that contain 
> nameConstraints that would  be violated by certificates 
> already in the path to this point are given lower priority 
> (or perhaps eliminated)." They should definitely be 
> eliminated. You know they can't be used to build a valid 
> path, so what's the point (unless you're working on building 
> an invalid path)?

I agree, this will be changed to eliminate certificates.
 
> * In section 3.5.9, you say "While this is viable, the 
> signature verifications required make it less attractive as 
> an elimination method." Usually, a CRL check only requires 
> one signature verification so "verification" should be singular.

Will do.
 
> You also say "It is suggested that this method only be used 
> for sorting and that CRLs are validated post path building." 
> As I noted above, fetching CRLs and performing signature 
> checks can be done in parallel with other work. It's a good 
> idea to do this so that you can discover revoked certs before 
> you have invested too much time in them (and also so that you 
> have the results of the revocation check ASAP).

See my above comments, we are trying to stay simple.
 
> You should also probably change this section to include 
> discussion of OCSP. Right now, it's very focussed on CRLs.

I agree, we will try and make it less specific to CRLs.

> * Here's a sorting method similar to the "Issuer Found in the 
> Path Cache" method, but better suited to building in reverse. 
> Check whether the subject of the candidate certificate 
> matches the issuer of a certificate sent by the target (in 
> SSL/TLS, S/MIME, etc.). If so, then the candidate certificate 
> should be ranked more highly because it is more likely to 
> lead to a path to the Target Certificate. You may also want 
> to do RDN Matching (as in 3.5.15) with the certificates sent 
> by the target.

I agree that this is a helpful sorting method.  With your permission, we
will add it to the document.
 
> * In section 3.5.15 (on RDN matching), you say "Additionally, 
> it should be noted that this method can require a lot of 
> processing if many trust anchors are present." Actually, this 
> should only require a few hash table lookups (of the RDNs).

Assuming you implement it with a hash table!
 
> * Section 3.5.18 could be clearer. I think you're saying that 
> the subject and issuer of the candidate certificate should 
> have lots of RDNs in common. But this could be understood to 
> be saying that the subject of the candidate certificate 
> should have lots of RDNs in common with the issuer of the 
> next certificate. Of course, they must match exactly so that 
> can't be what you're saying. But it would help if this 
> section was more explicit.

We will attempt to reword this to make it clearer.
 
> * Section 3.5.19 also should be clarified. The description of 
> the reverse method is much clearer than that of the forward 
> method. I suggest that you replace the forward method 
> language with language based on the reverse method language. 
> One change to the reverse method language, though. Instead of 
> saying "If an entity named by a reverse certificate", say "If 
> the subject of a certificate". There's no such thing as a 
> "reverse certificate".

We will reword the forward definition to be closer to the reverse.
 
> Note also that just because you find a name in the 
> certificate cache, that doesn't mean you have the right 
> certificates. There may be several different CAs with the 
> same name. Also, you may now have more clues (like AIA and 
> SIA) for finding certificates than you had before.
> You should be sure to pursue any such new clues.

Agree, that's why it's just a sort and not an eliminate rule.
 
> * In the Justification for 3.5.19, you say "The presence of 
> required directory values populated in the cache increases 
> the likelihood that all the required certificates and CRLs 
> needed to complete the path from this certificate to the 
> trust anchor (or target if building in
> reverse) are present in the cache from a prior path being 
> developed [...]". That's fine, but you might also want to 
> keep the actual path previously developed and look at that as 
> a prime candidate for the path this time.

We do recommend a cache for relationships and a cache for information in
section 2.6.  The idea of course is that given the cache of relationships
and the cache of information, you could reconstruct the previous path.  See
rule 3.5.10.
 
> * In section 3.5.20, you use the presence of a CRL in the CRL 
> cache to indicate whether a complete path through a CA has 
> previously been found. This is rather indirect. It would be 
> better to actually track which certs have been previously 
> included in valid paths. Keeping a copy of the path would 
> also be quite useful.

Agreed.  Again, rule 3.5.10 is more useful, and then this can be a secondary
rule to that.

> * The discussion of Forward Policy Chaining in section 4 
> overstates the benefits of policy checks when building in the 
> forward direction.
> We should discuss this more.

We don't feel like we're overstating, and welcome more discussion.

> * In section 5.2, you suggest that each name/key pair only be 
> allowed to appear once in a path. Since there is no such 
> requirement in X.509 or RFC 3280, this would violate 
> Criterion 1 as stated in section 2.2.
> You would miss some valid paths.

This is what happens when you have 5 authors on a document!  This
contradiction will be resolved, most likely by changing the Criterion 1
(since we feel strongly about the non-repetition of the name/key).  
> 
> * In section 6 (Retrieval Methods), you should mention 
> getting certificates and CRLs from the target (with S/MIME or 
> SSL/TLS, for instance). That's a *great* way to get 
> certificates and CRLs. The ones you get are usually highly valuable.

Yes we will add this.  Of course, most commercial implementations don't
provide CRLs in this way.

> * Sections 6.2 and 6.3 should include text that encourages 
> implementers to support AIA and SIA, especially HTTP. This 
> text from the end of section 6.4 could easily be adapted:
> 
>     However, implementers of path building  and validation 
> modules are strongly encouraged to support CRLDPs.  At  a 
> minimum, developers are encouraged to consider supporting the 
> LDAP  and HTTP transports; this will provide for 
> interoperability across a  wide range of existing PKIs.

We will add this (appropriately modified) text to 6.2 and 6.3.

> * In section 7, you should talk about prefetching and 
> parallel fetching. Both are good ways to improve the 
> performance of a cert path building implementation.

We will add these to section 7 as more advanced possibilities.

> * In section 7.1, you say "Certificate processing systems can 
> cache data retrieved from external sources for some period of 
> time, but not to exceed the useful period of the data (i.e., 
> an expired certificate need not be cached)." CRLs are often 
> issued well before the nextUpdate of the previous CRL. Could 
> you mention this and suggest that implementers check 
> periodically for updated CRLs? Similarly, 
> crossCertificatePairs may be updated on an unpredictable 
> basis. If you don't check back every so often, you'll never 
> know that a new cross certificate is available!

We could, although it will take a bit of additional writing to explain these
issues.  We will attempt to encourage retrievals before the nextUpdate has
passed.

> * The last bullet in section 7.1 offers a few suggestions for 
> other things to cache. I'd add to that list previously built 
> paths and partial paths. If the cache is safe from 
> unauthorized modifications (as with an in-memory cache), you 
> may also want to cache validation and signature check status 
> for certificates and CRLs.

We will add these additional recommendations.

> * In section 7.2 (Retrieval Order), you may want to consider 
> checking repositories in parallel instead of serially. Also, 
> you might want to run ahead with your path building and 
> validation while a network query is ongoing. Maybe you can 
> build and validate the path with just the certificates and 
> CRLs you have already (thus eliminating the need to wait for 
> the network query to complete). Anything to get the answer to 
> the user more quickly!

Agreed.  This has been noted a number of times in this message.
 
> * In section 8.1, you should probably add a statement that 
> path building can be used as a denial of service attack. Make 
> a series of simple requests to a server and cause it to do a 
> bunch of long path builds. To avoid this, the server can 
> limit the amount of resources it's willing to devote to a 
> path build. This amount can be reduced when the load is 
> heavy. And standard DOS protections like identifying 
> attackers can be employed.

Yes, we will add something about the threat of DOS attacks on server DPD
systems and systems that handle authentication.
 
> * Section 8.2 goes way beyond RFC 3280 and X.509. I know that 
> Santosh is working on getting this into X.509 and the 
> successor to RFC 3280.
> I'll debate the specifics of his proposal in that context. 
> But for this document, I think you should be careful to 
> explain that this goes beyond the standards. If you implement 
> it, you will violate Criterion
> 1 from section 2.2. Maybe the best thing to do is to just 
> briefly point out that there's an issue here and it's under 
> discussion in the standards groups. Once it's settled there, 
> this document can be revised to reflect whatever's agreed on.

This issue has been debated on the list and there has not been any objection
to it.  It does not violate Criterion 1 of Section 2.2 since the path for
the CRL signer needs to be developed for the same CA hierarchy as the
certification path.
 
> Minor Comments:

We will accept all your minor comments.

Steve, I know I speak for all of the authors when I thank you for this
detailed review of the document.  It is a tremendous help to know that
someone else has read and thought about the entire document, and even if you
have differing opinions on parts of it, you were willing to help create a
better finished product.

Sincerely,

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

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Mon, 17 May 2004 09:09:02 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Denis,
Another round will no longer than this is taking. Rather than read items
out of context, it is better to read the full proposal.
Trevor

* -----Original Message-----
* From: Denis Pinkas [mailto:[email-masked]]
* Sent: Monday, May 17, 2004 12:53 AM
* To: Trevor Freeman
* Cc: [email-masked]
* Subject: Re: SCVP & validation policies
* 
* Trevor,
* 
* > Hi Denis,
* 
* > As I said previous an OID is one of the possible options, but there
is
* > no consensus to make this mandatory so SCVP will continue to support
* > both options.
* 
* Making the OID optional as requested by Wen-Cheng Wang, does not
* necessarilly mean "supporting both options".
* 
* > I also don't see consensus that it is mandatory that a
* > SCVP server will always map a request back to the OID.
* 
* Many opinions, except one, are supporting this however.
* 
* > I will be posting SCVP 15 shortly so you can review the latest
draft.
* 
* An extract of the proposal sent to the mailing list and targeted to
this
* problem would probably save another round.
* 
* Denis
* 
* > Trevor
* >
* > -----Original Message-----
* > From: Denis Pinkas [mailto:[email-masked]]
* > Sent: Thursday, May 13, 2004 12:54 AM
* > To: Trevor Freeman
* > Cc: Florian Oelmaier; [email-masked]
* > Subject: Re: SCVP & validation policies
* >
* > Trevor,
* >
* > (text deleted)
* >
* > Florian said: "it is widespread consensus on this list that
* > this could be done with SCVP by the use of the OID as a reference
* > to the validation policy as the sole configuration item."
* >
* > I agree.
* >
* > To respond to a request from Wen-Cheng Wang, the OID of the
validation
* > policy should be optional in the request. However, if the OID of the
* > validation policy is not present in the request, then the OID of the
* > validation policy that has been used SHALL be returned by the SCVP
* > server in
* > the response. If the validation policy has dynamic parameters, then
* > these
* > parameters SHALL be returned too.
* >
* > Now, we need to move, Trevor.
* >
* > Would you propose in an e-mail extracts of an ASN.1 syntax that
would
* > accommodate these requirements for both the request and the
response,
* > focussing on the validation policy elements ?
* >
* > Thanks,
* >
* > Denis
* >
* > (text deleted)
* >
* >
* 

From: "Peter Hesse" <[email-masked]>
To: "'PKIX List'" <[email-masked]>
Cc: "'Steve Hanna'" <[email-masked]>, "'Wen-Cheng Wang'" <[email-masked]>
Subject: RE: Comments on Path Building I-D
Date: Mon, 17 May 2004 11:23:45 -0400
Sender: [email-masked]

Wen-Cheng,

I will reply to your comments inline.

> After reading the certpathbuild draft and the comments from Steve 
> Hanna, my feeling is that this draft is more like a paper (or thesis) 
> than a PKIX specification. I believe that is why Steve criticized the 
> text of the draft as if he is a reviewer of a PKI paper. I really 
> admire the authors and Steve's rich and deep knowledge of optimization 
> and implementation technique for path building. I must confess that I 
> gained much from reading "the paper" and the comments from Steve. 
> However, I doubt whether it is suitable for the PKIX WG to publish 
> "the paper" as an RFC.
> I think the text of the draft is good enough to become a paper on a 
> PKI conference proceedings or even  on a journal.
> But, that does not mean it will be a good PKIX RFC.

This document is meant to serve as an informational document which
implementers can read and use to make intelligent decisions when building
their own implementation.  Unlike most PKIX RFCs, which are standards-track
RFCs, this document is not intended to be prescriptive.  If you read RFC
2026, section 4.2.2 about Informational RFCs, I believe you will agree that
this document fits the mold of an Informational RFC quite well.

> As a faithful reader of PKIX specifications, I would expect that if 
> the PKIX WG would like to publish an RFC entitled "Certification Path 
> Building" then its text should focus on:
> 
> 1. defining what is a legal certification path
>            Can certificates with names in different encoding be 
> chained?
>            Can certificates with unmached issuer name and subject name
>            be chained by matching SKID and AKID?

These issues are covered in the document, and both have been brought up on
this list as recommended additions to RFC 3280.

> 2. defining a algorithm for certification path building, also 
> including
>          specifying the inputs to the algorithm and
>          specifying the outputs from the algorithm

As I mentioned above, an informational RFC should not be so prescriptive

> 3. specifying the format of certificate/CRL extensions (e.g. SKID, 
> AKID,AIA, SIA, CRLDP...) that are related to certification path 
> building.
>     E.g.,
>            the URL format of different procols (such as LDAP, HTTP, 
> FTP...)
>            (e.g., Should the LDAP URL contains the ";binary" option?)

These extensions are already specified in RFC3280.  The specifics of the
formats of these values may be best captured in a "best-practices" document
which I have suggested (in my response to Steve) as an additional document
to be considered by the group.  Aside from the restrictions identified in
section 4.2.1.7 of RFC3280, I do not think the values can be constrained any
further.

> 4. specifying how a compliant implementation should process
>     theose certificate/CRL extensions related certification path 
> building

Again, this is specified by RFC3280, our document makes no attempt to change
the way any extensions or fields are processed, nor should it.

>5. specifying what is the minimum set of repository retrieving  
>protocols (such as LDAP, HTTP, FTP, SMTP...) a compliant  
>implementation sould support and how these protocols should be  
>supported. E.g., What is the expected object format?
>                     (e.g., DER binary vs.Base64-encoded)
>                What is the expected MIME type if HTTP is used?

Again, this is best suited for a "best-practices" document.  There need not
be any minimum set of protocols defined as a standard, but a list of best
practices could give guidance on what protocols were most commonly used.

> 6. discussing security consideration
> 
> I believe that the PKIX certpathbuild specification should specify a 
> baseline certification path building algorithm in the fashion of RFC 
> 3280 specifying a basic certification path validation algorithm. The 
> purpose of defining the algorithm is for precisely describe the 
> expected result of the certification path building.

RFC3280 section 3.2 has identified a starting point, which is a
certification path.  We have provided a way to get from nothing to obtaining
that certification path, after which time you can perform validation; a
procedure that RFC3280 is silent on.  There cannot be a basic algorithm for
building defined as a PKIX standard, because this would make any algorithms
not designed in this fashion non-standard.  RFC3280 section 3.2 provides
enough to give us the basic algorithm.
 
> There is no need for a PKIX
> specification to teach implementators the optimization and 
> implementation technique for path building. It is up to the 
> implementators themselves to choose their own the optimization and 
> implementation technique. Isn't it?

Yes, it is up to the implementors.  Our document provides a recommendation
on what makes a good path builder, with example scenarios and an example
implementation.  All throughout, the document makes it clear that the
implementor can take or leave any of the suggestions.

> Therefore, I would like to suggest the authors to complete remove the 
> section 3 of the current draft. It is not only because a PKIX 
> specification is not supposed to be a paper or textbook for teaching 
> the optimization and implementation technique for path building, but 
> also because the optimization and implementation technique described 
> in that section is not, as Steve said, the consensus of the PKIX WG.
> I suggest that the draft sould spend more space and time to cover the 
> areas I mentioned above.
> (I know the current draft already covers them, but I think it is still 
> not in-depth enough.)

As I mentioned above, I believe that RFC3280 already covers the majority of
these issues, and in addition, a new document may be created to provide
guidance on the best practices of certification path development utilities.
As I mentioned in my message to Steve, I would be happy to collaborate on
such a document.

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

From: "Yasir Khan" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Signature in OCSP Request
Date: Mon, 17 May 2004 19:00:53 +0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_011A_01C43C41.46BCB6D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello

I have a question about the signature field in OCSP request. What =
exactly should it contain and what=20
algorithms can be used for OCSP request signing?=20

When i create a signature using MS CAPI, OCSP reponders are unable to =
verify the signatures whereas we
can verify it using CAPI. What data do we set in signature field =
exactly?

Regards,

Yasir

------=_NextPart_000_011A_01C43C41.46BCB6D0
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>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial color=3D#800080 size=3D2>
<DIV><BR>Hello</DIV>
<DIV>&nbsp;</DIV>
<DIV>I have a question about the signature field in OCSP request. What =
exactly=20
should it contain and what <BR>algorithms can be used for OCSP request =
signing?=20
</DIV>
<DIV>&nbsp;</DIV>
<DIV>When i create a signature using MS CAPI, OCSP reponders are unable =
to=20
verify the signatures whereas we<BR>can verify it using CAPI. What data =
do we=20
set in signature field exactly?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yasir</DIV>
<DIV>&nbsp;</DIV>
<DIV></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_011A_01C43C41.46BCB6D0--

Date: Mon, 17 May 2004 09:53:19 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
Subject: Re: SCVP & validation policies
Sender: [email-masked]

Trevor,

> Hi Denis,

> As I said previous an OID is one of the possible options, but there is
> no consensus to make this mandatory so SCVP will continue to support
> both options. 

Making the OID optional as requested by Wen-Cheng Wang, does not 
necessarilly mean "supporting both options".

> I also don't see consensus that it is mandatory that a
> SCVP server will always map a request back to the OID.

Many opinions, except one, are supporting this however.

> I will be posting SCVP 15 shortly so you can review the latest draft.

An extract of the proposal sent to the mailing list and targeted to this 
problem would probably save another round.

Denis

> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Thursday, May 13, 2004 12:54 AM
> To: Trevor Freeman
> Cc: Florian Oelmaier; [email-masked]
> Subject: Re: SCVP & validation policies
> 
> Trevor,
> 
> (text deleted)
> 
> Florian said: "it is widespread consensus on this list that
> this could be done with SCVP by the use of the OID as a reference
> to the validation policy as the sole configuration item."
> 
> I agree.
> 
> To respond to a request from Wen-Cheng Wang, the OID of the validation 
> policy should be optional in the request. However, if the OID of the 
> validation policy is not present in the request, then the OID of the 
> validation policy that has been used SHALL be returned by the SCVP
> server in 
> the response. If the validation policy has dynamic parameters, then
> these 
> parameters SHALL be returned too.
> 
> Now, we need to move, Trevor.
> 
> Would you propose in an e-mail extracts of an ASN.1 syntax that would 
> accommodate these requirements for both the request and the response, 
> focussing on the validation policy elements ?
> 
> Thanks,
> 
> Denis
> 
> (text deleted)
> 
> 

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Relationship between SAN and IAN?
Date: Mon, 17 May 2004 10:43:27 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0042_01C43BFB.C96DC1A0
Content-Type: text/plain;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

=0D=00=0A=
=00-=00-=00-=00-=00-=00 =00O=00r=00i=00g=00i=00n=00a=00l=00 =
=00M=00e=00s=00s=00a=00g=00e=00 =00-=00-=00-=00-=00-=00 =00=0D=00=0A=
=00F=00r=00o=00m=00:=00 =00F=00a=00i=00s=00a=00l=00 =
=00M=00a=00q=00s=00o=00o=00d=00 =00=0D=00=0A=
=00T=00o=00:=00 =
=00i=00e=00t=00f=00-=00p=00k=00i=00x=00@=00i=00m=00c=00.=00o=00r=00g=00 =
=00=0D=00=0A=
=00S=00e=00n=00t=00:=00 =00T=00u=00e=00s=00d=00a=00y=00,=00 =
=00F=00e=00b=00r=00u=00a=00r=00y=00 =002=004=00,=00 =002=000=000=004=00 =
=001=001=00:=000=004=00=0D=00=0A=
=00S=00u=00b=00j=00e=00c=00t=00:=00 =
=00R=00e=00l=00a=00t=00i=00o=00n=00s=00h=00i=00p=00 =
=00b=00e=00t=00w=00e=00e=00n=00 =00S=00A=00N=00 =00a=00n=00d=00 =
=00I=00A=00N=00?=00=0D=00=0A=
=00=0D=00=0A=
=00=0D=00=0A=
=00H=00e=00l=00l=00o=00 =00F=00o=00l=00k=00s=00,=00=0D=00=0A=
=00=0D=00=0A=
=00I=00 =00h=00a=00v=00e=00 =00a=00 =00q=00u=00e=00r=00y=00 =
=00f=00o=00r=00 =00c=00l=00a=00r=00i=00f=00i=00c=00a=00t=00i=00o=00n=00 =
=00a=00n=00d=00 =00n=00e=00e=00d=00s=00 =00y=00o=00u=00r=00 =
=00v=00i=00e=00w=00s=00.=00=0D=00=0A=
=00L=00e=00t=00 =00u=00s=00 =00c=00o=00n=00s=00i=00d=00e=00r=00 =
=00t=00h=00e=00r=00e=00 =00a=00r=00e=00 =00t=00w=00o=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00s=00 =00A=00 =
=00a=00n=00d=00 =00B=00 =00(=00p=00a=00r=00t=00 =00o=00f=00 =
=00t=00h=00e=00 =00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00i=00o=00n=00 =
=00p=00a=00t=00h=00)=00.=00 =00=0D=00=0A=
=00 =00 =00a=00.=00.=00 =00I=00f=00 =00A=00 =00i=00s=00 =
=00i=00s=00s=00u=00e=00r=00 =00o=00f=00 =00B=00 =00a=00n=00d=00 =
=00t=00h=00e=00r=00e=00 =00i=00s=00 =
=00S=00u=00b=00j=00e=00c=00t=00A=00l=00t=00N=00a=00m=00e=00 =
=00e=00x=00t=00e=00n=00s=00i=00o=00n=00 =00p=00r=00e=00s=00e=00n=00t=00 =
=00i=00n=00 =00A=00 =00a=00n=00d=00 =
=00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =00i=00n=00 =
=00B=00 =00a=00n=00d=00 =00v=00a=00l=00u=00e=00 =00o=00f=00 =
=00S=00u=00b=00j=00e=00c=00t=00A=00l=00t=00N=00a=00m=00e=00 =00i=00n=00 =
=00A=00 =00i=00s=00 =
=00"=00U=00R=00L=00=3D=00h=00t=00t=00p=00:=00/=00/=00w=00w=00w=00.=00t=00=
e=00s=00t=00s=00e=00r=00v=00e=00r=00n=00a=00m=00e=00.=00c=00o=00m=00"=00.=
=00 =00I=00s=00 =00t=00h=00e=00r=00e=00 =00a=00n=00y=00 =
=00r=00e=00q=00u=00i=00r=00e=00m=00e=00n=00t=00 =00i=00n=00 =
=00R=00F=00C=00 =002=004=005=009=00 =00o=00r=00 =003=002=008=000=00 =
=00o=00r=00 =00s=00o=00m=00e=00 =00w=00h=00e=00r=00e=00 =
=00e=00l=00s=00e=00 =00f=00o=00r=00 =
=00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =
=00v=00a=00l=00u=00e=00 =00(=00i=00f=00 =
=00p=00r=00e=00s=00e=00n=00t=00)=00 =00i=00n=00 =00B=00.=00 =00I=00 =
=00m=00e=00a=00n=00 =00i=00n=00 =00t=00h=00i=00s=00 =00c=00a=00s=00e=00 =
=00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =
=00v=00a=00l=00u=00e=00 =00m=00u=00s=00t=00 =
=00c=00o=00n=00t=00a=00i=00n=00 =
=00"=00U=00R=00L=00=3D=00h=00t=00t=00p=00:=00/=00/=00w=00w=00w=00.=00t=00=
e=00s=00t=00s=00e=00r=00v=00e=00r=00n=00a=00m=00e=00.=00c=00o=00m=00"=00?=
=00 =00=0D=00=0A=
=00 =00 =00b=00.=00.=00 =00S=00i=00m=00i=00l=00a=00r=00 =
=00q=00u=00e=00r=00y=00 =00f=00o=00r=00 =
=00S=00u=00b=00j=00e=00c=00t=00K=00e=00y=00I=00d=00e=00n=00t=00i=00f=00i=00=
e=00r=00 =00a=00n=00d=00 =
=00A=00u=00t=00h=00o=00r=00i=00t=00y=00K=00e=00y=00I=00d=00e=00n=00t=00i=00=
f=00i=00e=00r=00 =00t=00h=00a=00t=00 =00i=00f=00 =
=00S=00u=00b=00j=00e=00c=00t=00K=00e=00y=00I=00d=00e=00n=00t=00i=00f=00i=00=
e=00r=00 =00v=00a=00l=00u=00e=00 =00i=00s=00 =00o=00f=00 =
=006=000=00-=00b=00i=00t=00 =00l=00e=00n=00g=00t=00h=00 =00i=00n=00 =
=00A=00.=00 =00I=00s=00 =00R=00F=00C=00 =00a=00l=00l=00o=00w=00s=00 =
=00t=00o=00 =00p=00u=00t=00 =
=00A=00u=00t=00h=00o=00r=00i=00t=00y=00K=00e=00y=00I=00d=00e=00n=00t=00i=00=
f=00i=00e=00r=00 =00v=00a=00l=00u=00e=00 =00o=00f=00 =
=001=006=000=00-=00b=00i=00t=00 =00l=00e=00n=00g=00t=00h=00 =00i=00n=00 =
=00B=00?=00=0D=00=0A=
=00R=00e=00g=00a=00r=00d=00s=00,=00=0D=00=0A=
=00F=00a=00i=00s=00a=00l=00 =00M=00a=00q=00s=00o=00o=00d=00=0D=00=0A=
=00
------=_NextPart_000_0042_01C43BFB.C96DC1A0
Content-Type: text/html;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

=FF=FE<=00!=00D=00O=00C=00T=00Y=00P=00E=00 =00H=00T=00M=00L=00 =
=00P=00U=00B=00L=00I=00C=00 =
=00"=00-=00/=00/=00W=003=00C=00/=00/=00D=00T=00D=00 =00H=00T=00M=00L=00 =
=004=00.=000=00 =
=00T=00r=00a=00n=00s=00i=00t=00i=00o=00n=00a=00l=00/=00/=00E=00N=00"=00>=00=
=0D=00=0A=
=00<=00H=00T=00M=00L=00>=00<=00H=00E=00A=00D=00>=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00t=00e=00x=00t=00/=00h=00t=00m=00=
l=00;=00 =
=00c=00h=00a=00r=00s=00e=00t=00=3D=00u=00n=00i=00c=00o=00d=00e=00"=00 =
=00h=00t=00t=00p=00-=00e=00q=00u=00i=00v=00=3D=00C=00o=00n=00t=00e=00n=00=
t=00-=00T=00y=00p=00e=00>=00<=00B=00A=00S=00E=00 =00=0D=00=0A=
=00h=00r=00e=00f=00=3D=00"=00f=00i=00l=00e=00:=00/=00/=00F=00:=00\=00_=00=
B=00a=00c=00k=00U=00p=00-=00F=00M=00\=00E=00m=00a=00i=00l=00 =
=00S=00i=00g=00n=00a=00t=00u=00r=00e=00\=00"=00>=00<=00!=00D=00O=00C=00T=00=
Y=00P=00E=00 =00H=00T=00M=00L=00 =00P=00U=00B=00L=00I=00C=00 =
=00"=00-=00/=00/=00W=003=00C=00/=00/=00D=00T=00D=00 =00H=00T=00M=00L=00 =
=004=00.=000=00 =
=00T=00r=00a=00n=00s=00i=00t=00i=00o=00n=00a=00l=00/=00/=00E=00N=00"=00>=00=
=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=000=000=00.=003=005=000=002=00.=005=003=009=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=000=000=00.=003=005=000=002=00.=005=003=009=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00=0D=00=0A=
=00<=00S=00T=00Y=00L=00E=00>=00<=00/=00S=00T=00Y=00L=00E=00>=00=0D=00=0A=
=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=000=000=00.=003=005=000=002=00.=005=003=009=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00<=00/=00=
H=00E=00A=00D=00>=00=0D=00=0A=
=00<=00B=00O=00D=00Y=00 =
=00b=00g=00C=00o=00l=00o=00r=00=3D=00#=00f=00f=00f=00f=00f=00f=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00 =
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00:=00 =
=001=000=00p=00t=00 =00a=00r=00i=00a=00l=00"=00>=00-=00-=00-=00-=00-=00 =
=00O=00r=00i=00g=00i=00n=00a=00l=00 =00M=00e=00s=00s=00a=00g=00e=00 =
=00-=00-=00-=00-=00-=00 =00=0D=00=0A=
=00<=00D=00I=00V=00 =
=00s=00t=00y=00l=00e=00=3D=00"=00B=00A=00C=00K=00G=00R=00O=00U=00N=00D=00=
:=00 =00#=00e=004=00e=004=00e=004=00;=00 =
=00f=00o=00n=00t=00-=00c=00o=00l=00o=00r=00:=00 =
=00b=00l=00a=00c=00k=00"=00>=00<=00B=00>=00F=00r=00o=00m=00:=00<=00/=00B=00=
>=00 =00<=00A=00 =00=0D=00=0A=
=00h=00r=00e=00f=00=3D=00"=00m=00a=00i=00l=00t=00o=00:=00f=00a=00i=00s=00=
a=00l=00.=00m=00a=00q=00s=00o=00o=00d=00@=00a=00s=00c=00e=00r=00t=00i=00a=
=00.=00c=00o=00m=00"=00 =00=0D=00=0A=
=00t=00i=00t=00l=00e=00=3D=00f=00a=00i=00s=00a=00l=00.=00m=00a=00q=00s=00=
o=00o=00d=00@=00a=00s=00c=00e=00r=00t=00i=00a=00.=00c=00o=00m=00>=00F=00a=
=00i=00s=00a=00l=00 =00M=00a=00q=00s=00o=00o=00d=00<=00/=00A=00>=00 =
=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00B=00>=00T=00o=00:=00<=00/=00B=00>=00 =
=00<=00A=00 =
=00h=00r=00e=00f=00=3D=00"=00m=00a=00i=00l=00t=00o=00:=00i=00e=00t=00f=00=
-=00p=00k=00i=00x=00@=00i=00m=00c=00.=00o=00r=00g=00"=00 =00=0D=00=0A=
=00t=00i=00t=00l=00e=00=3D=00i=00e=00t=00f=00-=00p=00k=00i=00x=00@=00i=00=
m=00c=00.=00o=00r=00g=00>=00i=00e=00t=00f=00-=00p=00k=00i=00x=00@=00i=00m=
=00c=00.=00o=00r=00g=00<=00/=00A=00>=00 =00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00B=00>=00S=00e=00n=00t=00:=00<=00/=00B=00>=00 =
=00T=00u=00e=00s=00d=00a=00y=00,=00 =00F=00e=00b=00r=00u=00a=00r=00y=00 =
=002=004=00,=00 =002=000=000=004=00 =
=001=001=00:=000=004=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00B=00>=00S=00u=00b=00j=00e=00c=00t=00:=00<=00/=00=
B=00>=00 =00R=00e=00l=00a=00t=00i=00o=00n=00s=00h=00i=00p=00 =
=00b=00e=00t=00w=00e=00e=00n=00 =00S=00A=00N=00 =00a=00n=00d=00 =
=00I=00A=00N=00?=00<=00/=00D=00I=00V=00>=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00B=00R=00>=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00H=00e=00l=00l=00o=00 =
=00F=00o=00l=00k=00s=00,=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00I=00 =00h=00a=00v=00e=00 =00a=00 =
=00q=00u=00e=00r=00y=00 =00f=00o=00r=00 =
=00c=00l=00a=00r=00i=00f=00i=00c=00a=00t=00i=00o=00n=00 =00a=00n=00d=00 =
=00n=00e=00e=00d=00s=00&=00n=00b=00s=00p=00;=00y=00o=00u=00r=00 =
=00v=00i=00e=00w=00s=00.=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00L=00e=00t=00 =00u=00s=00 =
=00c=00o=00n=00s=00i=00d=00e=00r=00 =00t=00h=00e=00r=00e=00 =
=00a=00r=00e=00 =00t=00w=00o=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00s=00 =00A=00 =
=00a=00n=00d=00 =00B=00 =00(=00p=00a=00r=00t=00 =00o=00f=00 =
=00t=00h=00e=00 =00=0D=00=0A=
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00i=00o=00n=00 =
=00p=00a=00t=00h=00)=00.=00 =00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00U=00L=00>=00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00I=00f=00 =00A=00 =00i=00s=00 =
=00i=00s=00s=00u=00e=00r=00 =00o=00f=00 =00B=00 =00a=00n=00d=00 =
=00t=00h=00e=00r=00e=00 =00i=00s=00 =
=00S=00u=00b=00j=00e=00c=00t=00A=00l=00t=00N=00a=00m=00e=00 =
=00e=00x=00t=00e=00n=00s=00i=00o=00n=00 =00p=00r=00e=00s=00e=00n=00t=00 =
=00i=00n=00 =00A=00 =00a=00n=00d=00 =00=0D=00=0A=
=00 =00 =00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =
=00i=00n=00 =00B=00 =00a=00n=00d=00 =00v=00a=00l=00u=00e=00 =00o=00f=00 =
=00S=00u=00b=00j=00e=00c=00t=00A=00l=00t=00N=00a=00m=00e=00 =00i=00n=00 =
=00A=00 =00i=00s=00 =00=0D=00=0A=
=00 =00 =
=00"=00U=00R=00L=00=3D=00h=00t=00t=00p=00:=00/=00/=00w=00w=00w=00.=00t=00=
e=00s=00t=00s=00e=00r=00v=00e=00r=00n=00a=00m=00e=00.=00c=00o=00m=00"=00.=
=00 =00I=00s=00 =00t=00h=00e=00r=00e=00 =00a=00n=00y=00 =
=00r=00e=00q=00u=00i=00r=00e=00m=00e=00n=00t=00 =00i=00n=00 =
=00R=00F=00C=00 =002=004=005=009=00 =00o=00r=00 =00=0D=00=0A=
=00 =00 =003=002=008=000=00 =00o=00r=00 =00s=00o=00m=00e=00 =
=00w=00h=00e=00r=00e=00 =00e=00l=00s=00e=00 =00f=00o=00r=00 =
=00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =
=00v=00a=00l=00u=00e=00 =00(=00i=00f=00 =
=00p=00r=00e=00s=00e=00n=00t=00)=00 =00i=00n=00 =00B=00.=00 =00I=00 =
=00m=00e=00a=00n=00 =00i=00n=00 =00=0D=00=0A=
=00 =00 =00t=00h=00i=00s=00 =00c=00a=00s=00e=00 =
=00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =
=00v=00a=00l=00u=00e=00 =00m=00u=00s=00t=00 =
=00c=00o=00n=00t=00a=00i=00n=00 =00=0D=00=0A=
=00 =00 =
=00"=00U=00R=00L=00=3D=00h=00t=00t=00p=00:=00/=00/=00w=00w=00w=00.=00t=00=
e=00s=00t=00s=00e=00r=00v=00e=00r=00n=00a=00m=00e=00.=00c=00o=00m=00"=00?=
=00 =00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00S=00i=00m=00i=00l=00a=00r=00 =
=00q=00u=00e=00r=00y=00 =00f=00o=00r=00 =
=00S=00u=00b=00j=00e=00c=00t=00K=00e=00y=00I=00d=00e=00n=00t=00i=00f=00i=00=
e=00r=00 =00a=00n=00d=00 =
=00A=00u=00t=00h=00o=00r=00i=00t=00y=00K=00e=00y=00I=00d=00e=00n=00t=00i=00=
f=00i=00e=00r=00 =00t=00h=00a=00t=00 =00i=00f=00 =00=0D=00=0A=
=00 =00 =
=00S=00u=00b=00j=00e=00c=00t=00K=00e=00y=00I=00d=00e=00n=00t=00i=00f=00i=00=
e=00r=00 =00v=00a=00l=00u=00e=00 =00i=00s=00 =00o=00f=00 =
=006=000=00-=00b=00i=00t=00 =00l=00e=00n=00g=00t=00h=00 =00i=00n=00 =
=00A=00.=00 =00I=00s=00 =00R=00F=00C=00 =00a=00l=00l=00o=00w=00s=00 =
=00t=00o=00 =00p=00u=00t=00 =00=0D=00=0A=
=00 =00 =
=00A=00u=00t=00h=00o=00r=00i=00t=00y=00K=00e=00y=00I=00d=00e=00n=00t=00i=00=
f=00i=00e=00r=00 =00v=00a=00l=00u=00e=00 =00o=00f=00 =
=001=006=000=00-=00b=00i=00t=00 =00l=00e=00n=00g=00t=00h=00 =00i=00n=00 =
=00B=00?=00<=00/=00L=00I=00>=00<=00/=00U=00L=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00R=00e=00g=00a=00r=00d=00s=00,=00<=00/=00D=00I=00V=00=
>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00F=00a=00i=00s=00a=00l=00 =
=00M=00a=00q=00s=00o=00o=00d=00<=00/=00D=00I=00V=00>=00<=00/=00B=00O=00D=00=
Y=00>=00<=00/=00H=00T=00M=00L=00>=00=0D=00=0A=
=00
------=_NextPart_000_0042_01C43BFB.C96DC1A0--

Date: Sat, 15 May 2004 19:16:37 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: SCVP & validation policies
Cc: [email-masked]
Sender: [email-masked]

> [TF] Nice ideal, but Administrators of all descriptions make security
> related decisions.
As long as we continue with innovation prohibiting companies. :-) 

> [TF] Having the client be unaware that relay happened still seems a
> desirable simplification. All it takes is the server to process the rely
> reply. I am OK with including an SVVP response from another server for
> third party accountability, but not if the client is expected to process
> the embedded SCVP response.

I tend to agree. depends somewhat on the definition of 'process', clients
also do not process OCSP responses or time stamps, do they?

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Fri, 14 May 2004 12:27:40 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, May 14, 2004 10:25 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: SCVP & validation policies
* 
* 
* >
* >   [TF] One administrator can defile a policy and that policy can
consist
* > of n parameters living in some kind of object (XML in a file store,
* > attributes in a directory etc). Other administrators do not need to
be
* > intimately aware of the content of that object to use object, they
just
* > need a pointer which they can use. Therefore the number of
parameters in
* > the object is irrelevant. There is generally a perception that any
* > policy change has to be applied in a reasonable timeframe therefore
any
* > policy management system has regularly check for updates therefore
* > frequency of updates tends not to be a issue either. However I
really
* > don't expect SCVP policy of any type to have significant churn.
* 
* Policy changes are not to be applied by any workflow application
* administrator,
* i.e. client administrator. They are made by the security
administrator.
[TF] Nice ideal, but Administrators of all descriptions make security
related decisions.

* 
* > * But since you have responsed positively to Denis, I may
* > * not even understand what you are saying.
* 
* Well, since you have already agreed that it is posssible just to use a
* policy oid
* there is no need to discuss further whether the alternative is good,
* useful, practical or whatever.
* 
* > *
* > * Since three drafts, the whole text is unimplementable,
* > * i.e. almost a year, ...), so the following list of some
* > * (to me) open questions is not necessariy complete.
* > *
* > * - in what way a relay scvp can include an answer from another scvp
* > *   server? please allow to have a place for this. Just provide for
* > *   example a 'content-info' as a placeholder for time stamps, scvp
* > *   responses.
* 
* > [TF] Up to now one of our objective was to hide any complexity that
may
* > arise out of relay. There is also no guaranteed correlation between
* > relayed requests. A client may make a DPV request and the server may
* > intern make a DPD request to another SCVP server so embedding the
DPD
* > response to he DPV request is on no value.
* 
* inverse logic A ==> B is not the same as  not A ==> not B
* the fact that you may find one case where is doesn't make sense
* to include a response, doesn't mean that it never makes sense.
* And in the given example, in particular when there is no
* correlation, who can the realy prove that it has provided
* his a particular response based on whatever other response?
[TF] Having the client be unaware that relay happened still seems a
desirable simplification. All it takes is the server to process the rely
reply. I am OK with including an SVVP response from another server for
third party accountability, but not if the client is expected to process
the embedded SCVP response.

* 
* 
* 'our objective'? RFC 3379 says:
* 
*    The DPV request MUST allow the client to request that the server
*    include in its response additional information which will allow
*    relying parties not trusting the DPV server to be confident that
the
*    certificate validation has correctly been performed.  Such
*    information may (not necessarily exclusively) consist of a
*    certification path, revocation status information from authorized
CRL
*    issuers or authorized OCSP responders, revocation status
information
*    from CRL issuers or OCSP responders trusted under the validation
*    policy, time-stamp tokens from TSAs responders trusted under the
*    validation policy, or a DPV response from a DPV server that is
*                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
* 
*    trusted under the validation policy.  When the certificate is valid
*    according to the validation policy, the server MUST, upon request,
*    include that information in the response.  However, the server MAY
*    omit that information when the certificate is invalid or when it
*    cannot determine the validity.
* 
* > *
* > * - Is the Nonce field the response to the following req:
* > *
* > *    The DPV server MUST be able, upon request, copy a text field
* > provided
* > *    by the client into the DPV response.  As an example, this field
may
* > *    relate to the nature or reason for the DPV query.
* 
* ???? no answer?
[TF] The nonce is there to bind the request to the response.
* 
* > *
* > * - I'd like to know what others think about my compromise proposal
* > *   for requestor/responder.
* > *
* ???? no answer?
* 
* > * - I have some feeling that there are at least some different
* > * interpretation
* > *   of policies and object identifiers validation algoritithms, etc.
* > *
* > *   - OIDs used for a configuration
* > *   - oids to reference some globally recognised rules
* > *   - oids to define sysntaxes of validation algorihms.
* > [TF] Yes I have been thinking that an OID alone is to restrictive.
* 
* You already have for example a validation algorithm OID for
* name validation (like the qulifiers in Policyinfo)
* plus the required necessary parameters together with
* the configuration policy OID.
* 
* > Others may want to use a URL to point to a policy so we need a
couple of
* > built in choices plus an extension mechanism for other to define
other
* > reference types.
* 
* More than the qualifier logic in the PolicyInfo?
* 
* > *
* > * - It is not clear to me whether for example the name matching
* > algorithm
* > *   is at the right level of abstraction. I'd rather have an
* > *   algorithm that say: 'Can this cert be used for this keypurpose,
* > *   for the following names.' It maybe not useful to
* > *   burden the client with the details of adding keyusage and
* > *   compatible extendedkeyusage.
* > [TF] I was specially asked to do the name matching example because
it is
* > widely used today. I am sure others can submit other policy example
as
* > separate IDs.
* 
* I agree fully that the there is some good purpose of this kind of
* algorithm.
* I am just wondering whether the EXAMPLE specification is sufficiently
* well defined. Looks like may ask for three quarks with
* keyusage, extendedkeyusage and validation algorithm instead
* of asking for some more obvious atomic things.
* 
* If I am an ssl client or server, I simply don't care whether the
* actual certificate has whatever key usages or so, I just want a yes/no
* answer and maybe a path for logging. I just give the set of
* names and certs,
* 
* Do we need to distinguish email-protection certs for signing and
* encryption?
[TF] If you want to provide another example you can do so in another
draft.
* 

To: "Al Arsenault" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
From: Tom Gindin <[email-masked]>
Date: Fri, 14 May 2004 13:57:41 -0400
Sender: [email-masked]

        Al:

        The serialNumber attribute is not expected to contain the 
certificate serial number.  In its original definition it was supposed to 
contain the serial number of a piece of physical equipment, and it's 
defined to be a string rather than an integer like the certificate serial 
number.  There was a lot of discussion about which field to use for 
national identity numbers back in the fall of '99 as part of QC (see the 
thread of http://www.imc.org/ietf-pkix/old-archive-99/msg03041.html for an example), and the use is reflected in RFC 3739 section 3.1.2 (and 
also in the corresponding section of RFC 3039).
        IMHO, PI is better than this use of serialNumber, but serialNumber 
is not as unacceptable as it would be if it were supposed to match the 
certificate serial number.

                Tom Gindin

"Al Arsenault" <[email-masked]>
Sent by: [email-masked]
05/12/2004 09:30 PM

        To:     "Anders Rundgren" <[email-masked]>, "David P. Kemp" 
<[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: I-D ACTION:draft-ietf-pkix-pi-08.txt

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Anders Rundgren
> Sent: Wednesday, May 12, 2004 5:01 PM
> To: David P. Kemp; [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 
> >It is my hope that PI will become an RFC in the near future, so
> >that certificates (from an un-named large PKI :-) that currently
> >handle PIs by munging them into Common Name (e.g.,
> >CN="Kemp.David.P.0514101404") will have a saner alternative.
> 
> The de-facto standard, already engraved in *millions* of certs is
> putting 0514101404 in serialNumber. 
> 
> 

The problem with that is that "0514101404" is not expected to change; it's 
a number which stays with you as long as you're an employee of the 
company, or as long as you're a customer, or even all of your life.

The serialNumber is expected to change every time the certificate changes 
- commonly, when a certificate expires once a year, the new certificate 
has a new serialNumber.  It's considered seriously bad form to issue a 
"renewed" certificate with a different validity period and the same 
serialNumber.

Thus, those who put 0514101404 in "serialNumber" are just setting 
themselves up for trouble later on down the road.

(And as I've pointed out numerous times before, I know of organizations 
that put the equivalent of "0514101404" in subjectAltName, as a DNS Name! 
It's certainly possible, but that doesn't make it the "right thing" to do.

                                                 Al Arsenault

Date: Fri, 14 May 2004 19:24:41 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: SCVP & validation policies
Cc: [email-masked]
Sender: [email-masked]

> 
>   [TF] One administrator can defile a policy and that policy can consist
> of n parameters living in some kind of object (XML in a file store,
> attributes in a directory etc). Other administrators do not need to be
> intimately aware of the content of that object to use object, they just
> need a pointer which they can use. Therefore the number of parameters in
> the object is irrelevant. There is generally a perception that any
> policy change has to be applied in a reasonable timeframe therefore any
> policy management system has regularly check for updates therefore
> frequency of updates tends not to be a issue either. However I really
> don't expect SCVP policy of any type to have significant churn.   

Policy changes are not to be applied by any workflow application administrator,
i.e. client administrator. They are made by the security administrator.

> * But since you have responsed positively to Denis, I may
> * not even understand what you are saying.

Well, since you have already agreed that it is posssible just to use a policy oid
there is no need to discuss further whether the alternative is good,
useful, practical or whatever. 

> * 
> * Since three drafts, the whole text is unimplementable,
> * i.e. almost a year, ...), so the following list of some
> * (to me) open questions is not necessariy complete.
> * 
> * - in what way a relay scvp can include an answer from another scvp
> *   server? please allow to have a place for this. Just provide for
> *   example a 'content-info' as a placeholder for time stamps, scvp
> *   responses.

> [TF] Up to now one of our objective was to hide any complexity that may
> arise out of relay. There is also no guaranteed correlation between
> relayed requests. A client may make a DPV request and the server may
> intern make a DPD request to another SCVP server so embedding the DPD
> response to he DPV request is on no value.

inverse logic A ==> B is not the same as  not A ==> not B
the fact that you may find one case where is doesn't make sense
to include a response, doesn't mean that it never makes sense.
And in the given example, in particular when there is no
correlation, who can the realy prove that it has provided
his a particular response based on whatever other response?  

'our objective'? RFC 3379 says: 

   The DPV request MUST allow the client to request that the server
   include in its response additional information which will allow
   relying parties not trusting the DPV server to be confident that the
   certificate validation has correctly been performed.  Such
   information may (not necessarily exclusively) consist of a
   certification path, revocation status information from authorized CRL
   issuers or authorized OCSP responders, revocation status information
   from CRL issuers or OCSP responders trusted under the validation
   policy, time-stamp tokens from TSAs responders trusted under the
   validation policy, or a DPV response from a DPV server that is
                      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   trusted under the validation policy.  When the certificate is valid
   according to the validation policy, the server MUST, upon request,
   include that information in the response.  However, the server MAY
   omit that information when the certificate is invalid or when it
   cannot determine the validity.

> * 
> * - Is the Nonce field the response to the following req:
> * 
> *    The DPV server MUST be able, upon request, copy a text field
> provided
> *    by the client into the DPV response.  As an example, this field may
> *    relate to the nature or reason for the DPV query.

???? no answer?

> * 
> * - I'd like to know what others think about my compromise proposal
> *   for requestor/responder.
> * 
???? no answer?

> * - I have some feeling that there are at least some different
> * interpretation
> *   of policies and object identifiers validation algoritithms, etc.
> * 
> *   - OIDs used for a configuration
> *   - oids to reference some globally recognised rules
> *   - oids to define sysntaxes of validation algorihms.
> [TF] Yes I have been thinking that an OID alone is to restrictive.

You already have for example a validation algorithm OID for
name validation (like the qulifiers in Policyinfo)
plus the required necessary parameters together with
the configuration policy OID.  

> Others may want to use a URL to point to a policy so we need a couple of
> built in choices plus an extension mechanism for other to define other
> reference types.

More than the qualifier logic in the PolicyInfo? 

> * 
> * - It is not clear to me whether for example the name matching
> algorithm
> *   is at the right level of abstraction. I'd rather have an
> *   algorithm that say: 'Can this cert be used for this keypurpose,
> *   for the following names.' It maybe not useful to
> *   burden the client with the details of adding keyusage and
> *   compatible extendedkeyusage.
> [TF] I was specially asked to do the name matching example because it is
> widely used today. I am sure others can submit other policy example as
> separate IDs.

I agree fully that the there is some good purpose of this kind of algorithm. 
I am just wondering whether the EXAMPLE specification is sufficiently
well defined. Looks like may ask for three quarks with
keyusage, extendedkeyusage and validation algorithm instead
of asking for some more obvious atomic things.

If I am an ssl client or server, I simply don't care whether the
actual certificate has whatever key usages or so, I just want a yes/no
answer and maybe a path for logging. I just give the set of
names and certs, 

Do we need to distinguish email-protection certs for signing and encryption?

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Fri, 14 May 2004 09:35:30 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

See below

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, May 14, 2004 3:26 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: SCVP & validation policies
* 
* > Hi Peter,
* > The problem of having to push policy to clients of all descriptions
is a
* > well understood problem set. The infrastructure to do that is the
main
* > overhead. The number of parameters associated with that process is
not a
* > significant overhead.
* 
* You don't push parameters that are subject to change, you need to
handle
* updates, if you configure one id, the problem of updates is gone.
* 
* Whenever you can remove one parameter, you significantly reduce
* the potential problem space (about divide it at least by 2)

  [TF] One administrator can defile a policy and that policy can consist
of n parameters living in some kind of object (XML in a file store,
attributes in a directory etc). Other administrators do not need to be
intimately aware of the content of that object to use object, they just
need a pointer which they can use. Therefore the number of parameters in
the object is irrelevant. There is generally a perception that any
policy change has to be applied in a reasonable timeframe therefore any
policy management system has regularly check for updates therefore
frequency of updates tends not to be a issue either. However I really
don't expect SCVP policy of any type to have significant churn.   

* 
* But since you have responsed positively to Denis, I may
* not even understand what you are saying.
* 
* Since three drafts, the whole text is unimplementable,
* i.e. almost a year, ...), so the following list of some
* (to me) open questions is not necessariy complete.
* 
* - in what way a relay scvp can include an answer from another scvp
*   server? please allow to have a place for this. Just provide for
*   example a 'content-info' as a placeholder for time stamps, scvp
*   responses.
[TF] Up to now one of our objective was to hide any complexity that may
arise out of relay. There is also no guaranteed correlation between
relayed requests. A client may make a DPV request and the server may
intern make a DPD request to another SCVP server so embedding the DPD
response to he DPV request is on no value.
* 
* - Is the Nonce field the response to the following req:
* 
*    The DPV server MUST be able, upon request, copy a text field
provided
*    by the client into the DPV response.  As an example, this field may
*    relate to the nature or reason for the DPV query.
* 
* - I'd like to know what others think about my compromise proposal
*   for requestor/responder.
* 
* - I have some feeling that there are at least some different
* interpretation
*   of policies and object identifiers validation algoritithms, etc.
* 
*   - OIDs used for a configuration
*   - oids to reference some globally recognised rules
*   - oids to define sysntaxes of validation algorihms.
[TF] Yes I have been thinking that an OID alone is to restrictive.
Others may want to use a URL to point to a policy so we need a couple of
built in choices plus an extension mechanism for other to define other
reference types.
* 
* - It is not clear to me whether for example the name matching
algorithm
*   is at the right level of abstraction. I'd rather have an
*   algorithm that say: 'Can this cert be used for this keypurpose,
*   for the following names.' It maybe not useful to
*   burden the client with the details of adding keyusage and
*   compatible extendedkeyusage.
[TF] I was specially asked to do the name matching example because it is
widely used today. I am sure others can submit other policy example as
separate IDs.
* 
* 

Date: Fri, 14 May 2004 11:01:22 -0400
From: "David P. Kemp" <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
Sender: [email-masked]

The problem is that most PKIs do not support SN attributes
managed as in your "real world" example, they support
SN as disambiguator, as cited (not invented) by Denis.

Some tightly-managed PKIs (government and commercial) do
support SN attributes that are permanent references to a
user; in fact some do not even populate commonName and
use SN as the only user identifier.  In an ideal world,
all PKIs that populated the SN naming attribute would
put a Permanent Identifier in it.  This would be in
partial alignment with the wording of X.520, which
says:
   "The Serial Number attribute type specifies an
    identifier, the serial number of an object."

If you regard people as objects, then it is pretty clear
that the "serial number" of a person is something equivalent
to DNA; it doesn't change when the person changes names,
and it doesn't change depending on which CA issues the
person a certificate.  However, there are strong privacy
reasons for not putting a DNA equivalent into certificates,
and that's never going to happen.  So an alternative
like the PI RFC is required.  The requirements are:

1) mechanical applications must be able to tell reliably
and unambiguously (i.e., without installation-time
configuration) if a cert contains a PI, and if so, how
to extract it.

2) the PI doesn't change over the "functional lifetime"
of the person (the time the person has an account at
an institution, which can range up to most of a person's
natural lifetime).

3) the PI is assigned by a naming authority that is not
in general a CA.  One CA must be able to issue certs for
multiple institutions that create user accounts, and
multiple CAs must be able to issue certs for an account
at a single such institution (and are recognized as all
referring to the same account by the applications of
requirement #1).

If you can come up with a specification that uses the
SN attribute and satisfies each of these three requirements,
I will happily favor it over the Pinkas/Gindin proposal.
But I don't believe such a specification is possible.

Dave

Anders Rundgren wrote:

> Now assume that you don't have an e-mail address
> to stuff into the DN but you do have some kind of
> unique identifier.  Why put this somewhere else than
> in the DN?  An example shows how ugly it gets:
> 
> Denis' world:
> DN: CN=John Smith, serialNumber=3, O=ACME, C=US
> PI: OID.6.4.3.5.6.6.6.43.3, 05725277
> 
> The real world:
> DN: CN=John Smith, serialNumber=05725277, O=ACME, C=US
> The name space is given by the CA policy. Implicit or explicit.
> 
> Although esthetics is maybe not priority #1, I believe that
> "inventing" arbitrary disambiguing numbers when there is
> a perfectly valid number to use is a *very* hard sale. 
> However, most of the PI motivation goes away if the unique
> identifier is used as disambiguer and that's the problem in
> a nutshell.  Can you fix this dilemma, please tell us how!
> 
> 
> A solution for DoD
> ----------------------
> 
> Not that I believe you want my advice but here is a suggestion
> for DoD:
> 
> CN=David Kemp, serialNumber=05725277, DC=staffregistry1, DC=dod, DC=mil
> 
> Using this scheme you get globally unique identifiers (GUIDs)
> which is a much more needed and popular thing than finding
> new ways to complicate RP applications.  Why would a
> certificate ever contain more "name" info than this (+ S/MIME
> support in applicable cases)?
> 
> 
> rgds
> Anders
> 
> 

From: "Wen-Cheng Wang" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Tom Gindin" <[email-masked]>
Cc: "Santoni Adriano" <[email-masked]>, <[email-masked]>, "Stephen Kent" <[email-masked]>, <[email-masked]>, "Steve Hanna" <[email-masked]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String inencodingRDNs
Date: Fri, 14 May 2004 20:09:01 +0800
Sender: [email-masked]

I agree that if all RP implementations adopt X.500-like name matching
rules, then there is no need to issue name encoding rollover certificates.

Even so, we still need to clarify whether a certificate with same issuer
and subject names but in different encoding should be interpreted
as self-issued, because there is no way to prohibit CAs from issuing
such certificates (e.g., CA1-CA1-p-u-cert I mentioned in my recent post).

Wen-Cheng Wang

> 
> The whole encoding rollover certificate issue seems to be in error and
> should probably be deprecated.
> 
> Here is the reason:
> 
> Either you regard names of different encoding a name match or you don't.
> 
> X.509 matching rules for attributes caseIgnoreSyntax suggest that names
> in different encoding are a match if they can be concluded to express
> the same name.
> 
> RFC 3280 say that this is OK to implement, but you are allowed to
> disregard this and treat names of different encoding as no match
> 
> So.... If this IS accepted as a name match, then you don't need the
> rollover cert. It has no function since the path now works without it.
> 
> 
> The paradox is then the following: 
> If we fix name matching in RFC 3280, then there IS NO use of the
> encoding rollover cert any more (path works without it). If we on the
> other hand DON't fix this, then this certificate will neither be a self
> issued certificate by definition and thus it will in some cases break
> path validation.
> 
> 
> Stefan Santesson
> Program Manager, Windows Security
> 

Date: Fri, 14 May 2004 12:26:19 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: SCVP & validation policies
Cc: [email-masked]
Sender: [email-masked]

> Hi Peter,
> The problem of having to push policy to clients of all descriptions is a
> well understood problem set. The infrastructure to do that is the main
> overhead. The number of parameters associated with that process is not a
> significant overhead.

You don't push parameters that are subject to change, you need to handle
updates, if you configure one id, the problem of updates is gone.

Whenever you can remove one parameter, you significantly reduce 
the potential problem space (about divide it at least by 2)

But since you have responsed positively to Denis, I may
not even understand what you are saying.

Since three drafts, the whole text is unimplementable,
i.e. almost a year, ...), so the following list of some
(to me) open questions is not necessariy complete.  

- in what way a relay scvp can include an answer from another scvp
  server? please allow to have a place for this. Just provide for
  example a 'content-info' as a placeholder for time stamps, scvp
  responses.

- Is the Nonce field the response to the following req: 

   The DPV server MUST be able, upon request, copy a text field provided
   by the client into the DPV response.  As an example, this field may
   relate to the nature or reason for the DPV query.

- I'd like to know what others think about my compromise proposal
  for requestor/responder.

- I have some feeling that there are at least some different interpretation
  of policies and object identifiers validation algoritithms, etc.

  - OIDs used for a configuration
  - oids to reference some globally recognised rules
  - oids to define sysntaxes of validation algorihms. 

- It is not clear to me whether for example the name matching algorithm
  is at the right level of abstraction. I'd rather have an
  algorithm that say: 'Can this cert be used for this keypurpose,
  for the following names.' It maybe not useful to
  burden the client with the details of adding keyusage and 
  compatible extendedkeyusage. 

Date: Fri, 14 May 2004 11:59:45 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: SCVP & validation policies
Cc: [email-masked]
Sender: [email-masked]

> 
> Hi Denis,
> As I said previous an OID is one of the possible options, but there is
> no consensus to make this mandatory so SCVP will continue to support
> both options. I also don't see consensus that it is mandatory that a
> SCVP server will always map a request back to the OID.

I can live with this.

> I will be posting SCVP 15 shortly so you can review the latest draft.

Given the previous discussion, I'd like to see a possibility
that the request can be as simple as just sending in the certificate. 

Content-class: urn:content-classes:message
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String inencodingRDNs
Date: Fri, 14 May 2004 10:03:24 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>, "Tom Gindin" <[email-masked]>
Cc: "Santoni Adriano" <[email-masked]>, <[email-masked]>, "Stephen Kent" <[email-masked]>, <[email-masked]>, "Steve Hanna" <[email-masked]>
Sender: [email-masked]

The whole encoding rollover certificate issue seems to be in error and
should probably be deprecated.

Here is the reason:

Either you regard names of different encoding a name match or you don't.

X.509 matching rules for attributes caseIgnoreSyntax suggest that names
in different encoding are a match if they can be concluded to express
the same name.

RFC 3280 say that this is OK to implement, but you are allowed to
disregard this and treat names of different encoding as no match

So.... If this IS accepted as a name match, then you don't need the
rollover cert. It has no function since the path now works without it.

The paradox is then the following: 
If we fix name matching in RFC 3280, then there IS NO use of the
encoding rollover cert any more (path works without it). If we on the
other hand DON't fix this, then this certificate will neither be a self
issued certificate by definition and thus it will in some cases break
path validation.

Stefan Santesson
Program Manager, Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Wen-Cheng Wang
> Sent: den 14 maj 2004 09:21
> To: Tom Gindin
> Cc: Santoni Adriano; [email-masked]; Stephen Kent;
> [email-masked]; Stefan Santesson; Steve Hanna
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String
> inencodingRDNs
> 
> 
> Tom,
> 
> >
> >         The bottom line of the statements you have quoted is that
some
> > fully RFC 3280-compliant RP implementations will treat all rollover
> > certificates as self-issued, some will treat no rollover
certificates as
> > self-issued, and some will treat many rollover certificates as self-
> issued
> > but some as not.  Thus, whether a given rollover certificate is
deemed
> to
> > be self-issued by a compliant RP is implementation dependent -
probably
> a
> > worse situation than "rollover certificates are not interpreted as
> > self-issued".
> Yes, the current situation is that some RP implementations will treat
> name rollover certificates (if any) as self-issued but some will not.
> The root cause of inconsistency on interpreting self-issued
certificates
> among different implementations is the deficiency of name matching
> rules in RFC 3280 and the X.509 standard. There can be a debate
> on whether name rollover certificates should be interpreted as
> self-issued or not. However, the current situation is the current
> situation. The situation will not change unless the deficiency in
> RFC 3280 and the X.509 standard is mended and hopefully
> all RP implementations will migrate to  a consistent way of
> interpreting self-issued certificates. The point is that even if we
> finally
> agree that  "name rollover certificates should not interpreted as
> self-issued", we still need to revise or amend  RFC 3280 and the
> X.509 standard to make it clear.
> 
> >         IMHO, it would really help if we had a list of CA's who
encode
> > their current DN's using BMPString with characters in the surrogate
> range,
> > and whether they are compliant to UTF-16 or not, and a list of CA's
who
> > encode their current DN's using T61String.  Most other character
> > conversions under the ASN.1 standard are simple algorithms.
> >
> That might be an interesting investigation, but I do not think it will
> help for resolving the inconsistency on interpreting self-issued
> certificates. As I said above, the root cause is the deficiency of
> name matching rules. Paying more attention to mend the deficiency
> might be more helpful. If we have name matching rules that can take
> care of name string in different character sets and/or in different
> encoding, it will not only resolve the inconsistency on interpreting
> self-issued certificates but also will reduce the needs of issuing
> name rollover certificates.
> 
> Wen-Cheng Wang

Date: Fri, 14 May 2004 10:48:36 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs
Sender: [email-masked]

Tom Gindin wrote:

>        IMHO, it would really help if we had a list of CA's who encode 
>their current DN's using BMPString 
>
Probably not many. This might have happened mostly with some CA having 
left a few requests using BMPString slip in.

>with characters in the surrogate range, 
>and whether they are compliant to UTF-16 or not, 
>
I certainly believe nobody did that. Is it required to precise that 
UTF8String is the only reliable way to encode surrogate/non BMP unicode 
characters ?

>and a list of CA's who 
>encode their current DN's using T61String.
>
The bug database of Mozilla enables to localize some of them, for example :
E = [email-masked], CN = neam Gesellschaft für Kommunikationslösungen mbH, 
OU = Security, O = neam CA, C = DE (this is in T61)

Most of those CAs are clearly not used for certificates that were 
actually intended to be publicly distributed (thus did not care too much 
about interoperability problems).

There is in that database a very interesting case of a CA with a UTF8 
name that issued a cert with a BMPString name :
You can download that from this link :
http://bugzilla.mozilla.org/attachment.cgi?id=109214&action=view

I think this certainly demonstrate a CA wishing to switch to the use of 
UTF8String, but that unfortunately also allowed it's software to issue 
BMPString when it allowed "unicode" in certificate names.
Implementers should beware of such situations.

>  Most other character 
>conversions under the ASN.1 standard are simple algorithms.
>  
>

From: "Wen-Cheng Wang" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: "Santoni Adriano" <[email-masked]>, <[email-masked]>, "Stephen Kent" <[email-masked]>, <[email-masked]>, "Stefan Santesson" <[email-masked]>, "Steve Hanna" <[email-masked]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String inencodingRDNs
Date: Fri, 14 May 2004 15:20:42 +0800
Sender: [email-masked]

Tom,

>
>         The bottom line of the statements you have quoted is that some
> fully RFC 3280-compliant RP implementations will treat all rollover
> certificates as self-issued, some will treat no rollover certificates as
> self-issued, and some will treat many rollover certificates as self-issued
> but some as not.  Thus, whether a given rollover certificate is deemed to
> be self-issued by a compliant RP is implementation dependent - probably a
> worse situation than "rollover certificates are not interpreted as
> self-issued".
Yes, the current situation is that some RP implementations will treat
name rollover certificates (if any) as self-issued but some will not.
The root cause of inconsistency on interpreting self-issued certificates
among different implementations is the deficiency of name matching
rules in RFC 3280 and the X.509 standard. There can be a debate
on whether name rollover certificates should be interpreted as
self-issued or not. However, the current situation is the current
situation. The situation will not change unless the deficiency in
RFC 3280 and the X.509 standard is mended and hopefully
all RP implementations will migrate to  a consistent way of
interpreting self-issued certificates. The point is that even if we finally
agree that  "name rollover certificates should not interpreted as
self-issued", we still need to revise or amend  RFC 3280 and the
X.509 standard to make it clear.

>         IMHO, it would really help if we had a list of CA's who encode
> their current DN's using BMPString with characters in the surrogate range,
> and whether they are compliant to UTF-16 or not, and a list of CA's who
> encode their current DN's using T61String.  Most other character
> conversions under the ASN.1 standard are simple algorithms.
>
That might be an interesting investigation, but I do not think it will
help for resolving the inconsistency on interpreting self-issued
certificates. As I said above, the root cause is the deficiency of
name matching rules. Paying more attention to mend the deficiency
might be more helpful. If we have name matching rules that can take
care of name string in different character sets and/or in different
encoding, it will not only resolve the inconsistency on interpreting
self-issued certificates but also will reduce the needs of issuing
name rollover certificates.

Wen-Cheng Wang

To: "Wen-Cheng Wang" <[email-masked]>
Cc: "Santoni Adriano" <[email-masked]>, [email-masked], "Stephen Kent" <[email-masked]>, [email-masked], "Stefan Santesson" <[email-masked]>, "Steve Hanna" <[email-masked]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs
From: Tom Gindin <[email-masked]>
Date: Thu, 13 May 2004 20:07:55 -0400
Sender: [email-masked]

        Wan-Cheng:

        The bottom line of the statements you have quoted is that some 
fully RFC 3280-compliant RP implementations will treat all rollover 
certificates as self-issued, some will treat no rollover certificates as 
self-issued, and some will treat many rollover certificates as self-issued 
but some as not.  Thus, whether a given rollover certificate is deemed to 
be self-issued by a compliant RP is implementation dependent - probably a 
worse situation than "rollover certificates are not interpreted as 
self-issued".
        IMHO, it would really help if we had a list of CA's who encode 
their current DN's using BMPString with characters in the surrogate range, 
and whether they are compliant to UTF-16 or not, and a list of CA's who 
encode their current DN's using T61String.  Most other character 
conversions under the ASN.1 standard are simple algorithms.

                Tom Gindin

P.S. -  The above opinions are mine, and not necessarily those of my 
employer.

"Wen-Cheng Wang" <[email-masked]>
Sent by: [email-masked]
05/12/2004 05:10 AM

        To:     "Stefan Santesson" <[email-masked]>, "Stephen Kent" <[email-masked]>, 
"Santoni Adriano" <[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>, "Steve Hanna" 
<[email-masked]>
        Subject:        Re: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs

> Yes, you can do a lot of cool things in theory.
>
> The cruel truth is that your name encoding roll-over certs (e.g.
> CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

That is why I said that the definition of self-issued certificates in RFC
3280 (or maybe its definition in the X.509 standard itself) should
be revised or be clarified in son-of-3280 (or in an amendment of
the X.509 standard as well).

>
> RFC 3280 section 6.1:
>    A certificate is self-issued if the DNs that appear in the subject
>    and issuer fields are identical and are not empty.
>
> RFC 3280 section 4.1.2.4:
>       (a)  attribute values encoded in different types (e.g.,
>       PrintableString and BMPString) MAY be assumed to represent
>       different strings;

Remenber that RFC 3280 section 4.1.2.4 also said:

   Implementations of this profile are permitted to use the comparison
   algorithm defined in the X.500 series.

In that respect, you can not said that name rollover certificates are not
self-issued.

>
> So in current implementations of RFC 3280, many valid certificates will
> fail after introduction of name rollover certs in the chain, because
> path validation will not treat them as self-issued.

I admit that most CURRENT implementations of RFC 3280 path
validation will fail to treat name rollover certificates as self-issued, 
but
it does not mean that we should not recommend FUTURE revisions
of those implementations and new implementations to treat them as
self-issued.

>
> Further, the name constraint problem persists, adds to this but also
> exist regardless of this problem.
>
> RFC 3280 section 4.2.1.11
>    When applying restrictions of the form directoryName, an
>    implementation MUST compare DN attributes.  At a minimum,
>    implementations MUST perform the DN comparison rules specified in
>    Section 4.1.2.4.

That is why I said RFC 3280 path validation algorithm should also be
revised.

>
> Fixing next version of RFC 3280 to include better name matching rules is
> a good thing but far from enough to take care of real problems with
> current infrastructure.

Fixing next version of RFC 3280 does not magically take care of real
problems with current infrastructure, but it encourge current 
infrastructure
to migrate to solve the problems.

>
> We have to try to keep in mind what we make all this hassle for!!
>
> This is NOT about whether we should use UTF-8 or not to accommodate
> complex character sets!! This is about what we are prepared to do to
> make sure NOTHING is encoded as PrintableString WHEN PrintableString is
> sufficient.
>
> This old transition rule was created in RFC 2459 before the modern path
> validation algorithm was invented and before self-issued certificates
> was a special case.

That does not mean that name rollover certificates can not solve the
mixed name-encoding  problem.

>
> Let's just admit that we overlooked this issue when we created RFC 3280
> and reshaped path validation. It was an understandable human error,
> which lead to a defect.

Yes, RFC 3280 indeed overlooked this issue. That is why it should be
revised.

>
> So let's then also admit that REQUIRING UTF-8 when printableString is
> sufficient, is not a very good idea when all practical matters are
> measured, and that it never should have made it to more than a
> RECOMMENDATION.

Isn't it the IETF policy to encourge all new implementations to migrate
to support UTF-8? The philosophy is that if one encoding is sufficient to
cover universal characters, why should we recommend two?

>
> Whatever we say here, this is a requirement that many implementers will
> have to ignore for a many years to come.

Conformance to any IETF RFC is all voluntary. No one can enfoce any
implementer for that if the implementer chooses to ignore the requirement
or recommendation of any IETF RFC. RFC 3280 might not have the
power to enforce all implementation to migrate to UTF-8 encoding.
However, as an IETF RFC, it definitely has a great effect. At least, I
see more and more applications can correctly handle certificates with
named in UTF-8 encoding. Therefore, I prefer to see son-of-3280 to
continue requiring conformant implementations to migrate to UTF-8
encoding.

Wen-Cheng Wang

From: "Anders Rundgren" <[email-masked]>
To: "David P. Kemp" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Thu, 13 May 2004 21:59:41 +0200
Sender: [email-masked]

David,
I don't know if you really care, but there are reasons behind
my arguments, beyond just "opinions" or personal taste.

>SubjectAltName brings some syntax-enforced discipline
>to certificate naming.  Feel free to ignore it, and even
>to urge others to ignore it, 

*I* don't have to do this.  Putting RFC822 names in subject
DNs is the default behavior of every major CA software
package there is.

In fact 9 out of 10 certificates used for signing messages
to the PKIX-list(!) follow this standard, in spite of being
deprecated by S/MIME and RFC3280.

>but at least feel a twinge of shame when you do so.

Well, I believe the RFC3280 should in the coming revision
refrain from calling the industry standard "legacy".

Harry the PKI amateur
--------------------------

In quite a number of RP applications the subject DN is
the *only* identity information used, as most folks actually
believed that the "subject distinguished name" really is
the name of the subject.  After looking at a number of
commercial certs this looked like a fact.  That DNs are
created to suit the needs of a directory is not an absolute
truth anymore.  In particular as many RPs don't store
certificates in directories but in "flat" databases. 
In most cases external certificates are not stored at all,
except by CAs for revocation services etc!

Encrypted mail is a microscopic application which
makes the whole DIT-story of marginal interest.
That's was an "opinon" though :-)

The "art discussion"
---------------------

Now assume that you don't have an e-mail address
to stuff into the DN but you do have some kind of
unique identifier.  Why put this somewhere else than
in the DN?  An example shows how ugly it gets:

Denis' world:
DN: CN=John Smith, serialNumber=3, O=ACME, C=US
PI: OID.6.4.3.5.6.6.6.43.3, 05725277

The real world:
DN: CN=John Smith, serialNumber=05725277, O=ACME, C=US
The name space is given by the CA policy. Implicit or explicit.

Although esthetics is maybe not priority #1, I believe that
"inventing" arbitrary disambiguing numbers when there is
a perfectly valid number to use is a *very* hard sale. 
However, most of the PI motivation goes away if the unique
identifier is used as disambiguer and that's the problem in
a nutshell.  Can you fix this dilemma, please tell us how!

A solution for DoD
----------------------

Not that I believe you want my advice but here is a suggestion
for DoD:

CN=David Kemp, serialNumber=05725277, DC=staffregistry1, DC=dod, DC=mil

Using this scheme you get globally unique identifiers (GUIDs)
which is a much more needed and popular thing than finding
new ways to complicate RP applications.  Why would a
certificate ever contain more "name" info than this (+ S/MIME
support in applicable cases)?

rgds
Anders

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Thu, 13 May 2004 08:58:25 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Denis,
As I said previous an OID is one of the possible options, but there is
no consensus to make this mandatory so SCVP will continue to support
both options. I also don't see consensus that it is mandatory that a
SCVP server will always map a request back to the OID.
I will be posting SCVP 15 shortly so you can review the latest draft.
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, May 13, 2004 12:54 AM
To: Trevor Freeman
Cc: Florian Oelmaier; [email-masked]
Subject: Re: SCVP & validation policies

Trevor,

(text deleted)

Florian said: "it is widespread consensus on this list that
this could be done with SCVP by the use of the OID as a reference
to the validation policy as the sole configuration item."

I agree.

To respond to a request from Wen-Cheng Wang, the OID of the validation 
policy should be optional in the request. However, if the OID of the 
validation policy is not present in the request, then the OID of the 
validation policy that has been used SHALL be returned by the SCVP
server in 
the response. If the validation policy has dynamic parameters, then
these 
parameters SHALL be returned too.

Now, we need to move, Trevor.

Would you propose in an e-mail extracts of an ASN.1 syntax that would 
accommodate these requirements for both the request and the response, 
focussing on the validation policy elements ?

Thanks,

Denis

(text deleted)

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Fri, 14 May 2004 02:36:43 +1200
Sender: [email-masked]

"Al Arsenault" <[email-masked]> writes:

>(And as I've pointed out numerous times before, I know of organizations that
> put the equivalent of "0514101404" in subjectAltName, as a DNS Name!  It's
> certainly possible, but that doesn't make it the "right thing" to do.

I've seen 'em in uniqueIDs, from a couple of European CAs.

Peter.

Date: Thu, 13 May 2004 09:54:01 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "'Trevor Freeman'" <[email-masked]>
CC: Florian Oelmaier <[email-masked]>, [email-masked]
Subject: Re: SCVP & validation policies
Sender: [email-masked]

Trevor,

(text deleted)

Florian said: "it is widespread consensus on this list that
this could be done with SCVP by the use of the OID as a reference
to the validation policy as the sole configuration item."

I agree.

To respond to a request from Wen-Cheng Wang, the OID of the validation 
policy should be optional in the request. However, if the OID of the 
validation policy is not present in the request, then the OID of the 
validation policy that has been used SHALL be returned by the SCVP server in 
the response. If the validation policy has dynamic parameters, then these 
parameters SHALL be returned too.

Now, we need to move, Trevor.

Would you propose in an e-mail extracts of an ASN.1 syntax that would 
accommodate these requirements for both the request and the response, 
focussing on the validation policy elements ?

Thanks,

Denis

(text deleted)

From: "Al Arsenault" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Wed, 12 May 2004 21:30:37 -0400
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Anders Rundgren
> Sent: Wednesday, May 12, 2004 5:01 PM
> To: David P. Kemp; [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 
> >It is my hope that PI will become an RFC in the near future, so
> >that certificates (from an un-named large PKI :-) that currently
> >handle PIs by munging them into Common Name (e.g.,
> >CN="Kemp.David.P.0514101404") will have a saner alternative.
> 
> The de-facto standard, already engraved in *millions* of certs is
> putting 0514101404 in serialNumber. 
> 
> 

The problem with that is that "0514101404" is not expected to change; it's a number which stays with you as long as you're an employee of the company, or as long as you're a customer, or even all of your life.

The serialNumber is expected to change every time the certificate changes - commonly, when a certificate expires once a year, the new certificate has a new serialNumber.  It's considered seriously bad form to issue a "renewed" certificate with a different validity period and the same serialNumber.

Thus, those who put 0514101404 in "serialNumber" are just setting themselves up for trouble later on down the road.

(And as I've pointed out numerous times before, I know of organizations that put the equivalent of "0514101404" in subjectAltName, as a DNS Name!  It's certainly possible, but that doesn't make it the "right thing" to do.

			Al Arsenault

Date: Wed, 12 May 2004 18:12:04 -0400
From: "David P. Kemp" <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
Sender: [email-masked]

It is certainly technically possible to put any attribute
into the subject name syntax.  An unfortunate side effect
of an infinitely-flexible syntax is that de-facto standards
such as those you cite can arise.

DNS (and by extension, email address) is a namespace rooted
in the TLDs (.com, .edu, ...).  PIs are another
namespace rooted either in some CA-specific environment
(policy=CA) or in an independent manner (by assigning agency)
that allows multiple CAs to issue certificates to one
identifiable user.  Subject Distinguished Names are
intended to be a third namespace, typically rooted by Country.

When you say "just stuff an email address in the middle of
a DN", that is equivalent to saying "just stuff a DN in
the middle of an email address:
"dpkemp@missi.(C=US,O=DoD,CN=Dave).ncsc.mil"  Fortunately,
RFC822 prohibits such foolishness in a way that cannot be
circumvented by fools.  Unfortunately, X.509 DN syntax does
not prohibit anything, and it is up to system architects
to establish rules that enable DNs to form a namespace
rather than a cloaca for miscellaneous unrelated data.
It is as easy for CAs to ignore those rules as it is
for Harry Homeowners to ignore electrical codes and wire
their basements without grounding and with hot and neutral
lines connected randomly.  The fact that something can be
done and is in fact done millions of times does not make
it a good idea.

SubjectAltName brings some syntax-enforced discipline
to certificate naming.  Feel free to ignore it, and even
to urge others to ignore it, but at least feel a twinge
of shame when you do so.

Anders Rundgren wrote:

>>It is my hope that PI will become an RFC in the near future, so
>>that certificates (from an un-named large PKI :-) that currently
>>handle PIs by munging them into Common Name (e.g.,
>>CN="Kemp.David.P.0514101404") will have a saner alternative.
> 
> 
> The de-facto standard, already engraved in *millions* of certs is
> putting 0514101404 in serialNumber. 
> 
> This is almost as de-facto standard as putting e-mail addresses in DNs
> which in turn is almost as de-facto standard as using URIs for naming
> globally unique objects.
> 
> C:\Internet-Drafts>del draft-ietf-pkix-pi-*.txt
> 
> :-)
> 
> Pardon my complaints, let there be an RFC!  But don't expect
> this scheme to become the trend.
> 
> There is a slight problem with the whole idea.  Either RPs require
> and act upon the PI-data or they don't care about it.  This in my
> opinion makes the extension redundant or is just another way
> to screw up validation.
> 
> If you on top of this add policy extensions I believe a real disaster
> is in the making.
> 
> Anders
> 

From: "Anders Rundgren" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Wed, 12 May 2004 23:01:23 +0200
Sender: [email-masked]

>It is my hope that PI will become an RFC in the near future, so
>that certificates (from an un-named large PKI :-) that currently
>handle PIs by munging them into Common Name (e.g.,
>CN="Kemp.David.P.0514101404") will have a saner alternative.

The de-facto standard, already engraved in *millions* of certs is
putting 0514101404 in serialNumber. 

This is almost as de-facto standard as putting e-mail addresses in DNs
which in turn is almost as de-facto standard as using URIs for naming
globally unique objects.

C:\Internet-Drafts>del draft-ietf-pkix-pi-*.txt

:-)

Pardon my complaints, let there be an RFC!  But don't expect
this scheme to become the trend.

There is a slight problem with the whole idea.  Either RPs require
and act upon the PI-data or they don't care about it.  This in my
opinion makes the extension redundant or is just another way
to screw up validation.

If you on top of this add policy extensions I believe a real disaster
is in the making.

Anders

From: "Florian Oelmaier" <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 21:16:18 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> Hi Denis,
> Any software does not have a clue abut most things in life. 
> To operate the administrator of the client has to have 
> understand what is going on. If the administrator does not 
> understand what the implications of their actions are, then 
> they make mistakes. Your premise is that simplified 
> administration is only possible in the case of SCVP by the 
> use of the OID. Given there is a vast quantity of 
> administration software which his able to present simple 
> choices to the administrator while at the same time 
> configuring multiple parameters without there knowledge mean 
> this is not the case. Trevor

There are different roles in the administration. And the "usual
administrator for client software" is a rather different role than the
role of a security administrator. In the meantime (mostly due to the bad
experiences) this is a general accepted model. In most enterprises there
are different people responsible for operating the client and for
managing the security. 

Thus I dont think it is necessary for a client administrator to
understand the implications of settings necessary for certificate
validation. From my perspective there is a move in all areas of security
to strip as many security relevant configuration setting from the client
as possible. And I think it is widespread consensus on this list that
this could be done with SCVP by the use of the OID as a reference to the
validation policy as the sole configuration item.

Florian

> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Wednesday, May 12, 2004 12:25 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: Re: SCVP & validation policies
> 
> Trevor,
> 
> > You also have to understand enough so that the administrative
> > configuration of the client is generating the right kind of 
> request. 
>  > > SCVP client is ?only following orders? in many instances 
> and has from a The SCVP client is "only following orders" in 
> many instances and has  > from a perspective no idea if it is 
> the right kind of request, only if it  > is well formed to 
> the rules it has been given. Both the administrator of
> > the client and the administrator of the server has to understand in
> much 
> > grater detail what the given policy is. Once you abstract though the
> > OID, you are placing a greater burden on the OOB admin to admin
> process.
> 
> The client does not have to "understand" what the validation given
> policy is.
> 
> The client only needs to know that, for a given application a 
> given OID
> for 
> the validation policy is needed. He does not need to have a 
> clue of the 
> details of the validation policy which may remain fully opaque to him.
> 
> This means that any validation specific parameter must *not* 
> be part of
> the 
> standard request.
> 
> Denis
> 
> 
> > Trevor
> > 
> >  
> > 
> >
> --------------------------------------------------------------
> ----------
> > 
> > From: James Jing [mailto:[email-masked]]
> > Sent: Tuesday, May 11, 2004 5:09 PM
> > To: Trevor Freeman; [email-masked]
> > Subject: RE: SCVP & validation policies
> > 
> >  
> > 
> > Agree that the client needs to have all the data in order 
> to build the
> 
> > request. However, I think ?understand? is too strong a requirement.
> The 
> > client may not need to ?understand? the data, some of which may be 
> > factors affecting the server only. Perhaps I am too 
> pedantic about the
> 
> > word ?understand?.
> > 
> >  
> > 
> > Back to indirection, if ?understanding? is not a 
> requirement, then the
> 
> > client need not to be aware that an OID is an indirection 
> to a set of 
> > policies.
> > 
> >  
> > 
> > James
> > 
> >  
> > 
> >
> --------------------------------------------------------------
> ----------
> > 
> > From: Trevor Freeman [mailto:[email-masked]]
> > Sent: Wednesday, 12 May 2004 9:49 AM
> > To: James Jing; [email-masked]
> > Subject: RE: SCVP & validation policies
> > 
> >  
> > 
> > The client has to understand what is required to build a 
> request i.e.
> > What data does it need to supply to the server. It does not 
> need to be
> > aware of the factors which effect the server.
> > Trevor
> > 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of James Jing
> > Sent: Tuesday, May 11, 2004 4:01 PM
> > To: [email-masked]
> > Subject: RE: SCVP & validation policies
> > 
> >  
> > 
> > I think policy OIDs should remain abstract, or at least can be
> abstract.
> > That is that there is no requirement for the client software to
> > understand the parameters.
> > 
> > I am more thinking of using SCVP to validate a certificate in the
> > context of a transaction, where the policy OID in SCVP might be used
> to
> > identify such a context to the server.
> > 
> > For example, a certificate validation request is carried out with
> regard
> > to the acceptability of the holder's creditworthiness in the context
> of
> > a credit-based transaction. In this case, the policy OID 
> could be used
> > to indicate the class of assuarances that the CA's CSP provides for,
> > resulting in the server selecting a subset of acceptable trust
> anchors.
> > 
> > James
> > 
> >  
> > 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[email-masked]]
> > Sent: Friday, 7 May 2004 6:28 AM
> > To: Trevor Freeman
> > Cc: [email-masked]
> > Subject: RE: SCVP & validation policies
> > 
> >  
> > 
> > At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
> >>Hi Steve,
> >>If you want to have a shorthand notation for a validation policy,
> given
> > 
> >>we have a finite set of parameters, the I don't see the value of
> >>indirection via an OID. Using a hash of the set of inputs provides a
> >>way of expressing the same thing without introducing 
> ambiguity of does
> >>both parties have a common understating of that this means. At some
> >>point someone has to define the policy in terms of the 3280 input
> > parameters.
> >>That definition is just as applicable and consumable by the 
> client as
> a
> > 
> >>server therefore what did we gain from the shorthand notation? It
> would
> > 
> >>be pretty trivial to define some XML which would allow that set of
> >>validation parameters to be imported by any SCVP entity.
> >>Trevor
> > 
> > Trevor,
> > 
> > It is not indirection via an OID, it is identification via an OID.
> > Clients never have to be aware of the parameters if we use 
> an OID, and
> > simplification of clients is one of the goals of SCVP. So I cannot
> agree
> > with your comment that clients have to be able to consume these
> > parameters.
> > 
> > Given that as a basis, it seems that we are debating whether to use
> OIDs
> > or to create some other form of identifier via hashing parameters. I
> > don't see the latter as attractive, since it requires additional
> > specification of the canonicalization and encoding of the parameters
> to
> > ensure consistency in hash computation between client and server.
> > 
> > Steve
> > 
> >  
> > 
> > This e-mail, and any attachments hereto, is intended only for use by
> the 
> > named addressee(s) and may contain legally privileged and/or 
> > confidential information.  If you are not the intended 
> recipient, you 
> > are hereby notified that any dissemination, distribution or 
> copying of
> 
> > this e-mail, and any attachments hereto, is strictly prohibited.  If
> you 
> > have received this transmission in error, please notify me 
> immediately
> 
> > and permanently delete the original and all copies and printouts of
> this 
> > e-mail.
> > 
> 
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 12:00:39 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
The problem of having to push policy to clients of all descriptions is a
well understood problem set. The infrastructure to do that is the main
overhead. The number of parameters associated with that process is not a
significant overhead.
Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2004 11:23 AM
To: [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: SCVP & validation policies

trevor,

Your clients may need to be updated each time you change anything
in the structure of your certs, or in the rules of the policies,

Any code that can be avoided, seems good to me in line with
the requirement for dumb client support.   

> 
> Hi Denis,
> Any software does not have a clue abut most things in life. To operate
> the administrator of the client has to have understand what is going
on.
> If the administrator does not understand what the implications of
their
> actions are, then they make mistakes. Your premise is that simplified
> administration is only possible in the case of SCVP by the use of the
> OID. Given there is a vast quantity of administration software which
his
> able to present simple choices to the administrator while at the same
> time configuring multiple parameters without there knowledge mean this
> is not the case.
> Trevor
> 

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 11:28:18 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Wen-Cheng,
In scenario 1, the use of and validation policy OID option in a request
is superfluous. The SCVP client simply submits the request and the
server uses its default policy.
In scenario 3 there are two way to achieve this with SCVP. The client
and can be configured with a set of OIDs to represent the policy, or
they can by configured wit the set of parameters to submit. In both
cases the SCVP server certifies the request matches its local policy
before processing the request.
Trevor

-----Original Message-----
From: Wen-Cheng Wang [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2004 2:21 AM
To: Denis Pinkas; Trevor Freeman
Cc: Stephen Kent; [email-masked]
Subject: Re: SCVP & validation policies

I would like to support that even the validation policy OID itself is
optional for the client to use. As I stated in my earlier post, if a
client
fully trust the validation server, then it might not have to specify a
validation policy OID in its request. In that case, it means that the
client trusts the validation server to adopt the default validation
policy
predefinied by the management authority of the application domain
(such as an enterprise). For example, in scenario 1 and scenario 3 I
mentioned in my earlier post, if the client request does not specify any
validation policy OID, then server will adopt the default validation
policy. For you reference, scenario 1 and scenario 3 are as follows:

Scenario 1 (single central-managed vlidation policy)

  DPV server:
      only supports a single central-managed vlidation policy
      the validation policy implies all policy-dependent parameters

  DPV client:
      the validation request may optionally specify the vlidation policy
OID
      the validation request needs not specify any policy-dependent
          parameters

Scenario 3 (multiple central-managed vlidation policies with a default
validation policy)

  DPV server:
      supports multiple central-managed vlidation policies with one of
them
          is the default
      each validation policy implies its policy-dependent parameters

  DPV client:
      the validation request should specify the vlidation policy OID
      if the request did not specify the vlidation policy OID, then the
         server will use the default one
      the validation request needs not to specify any policy-dependent
         parameters

These are the simplest cases of the use of DPV protocol. I hope that
basic SCVP syntax should support these simplest cases more clearly.
(I mean that the ambiguity in the current syntax should be reduced.)

In contrast to these simplest cases, an extreme case of the use of
DPV protocol is the case where there is no any predefined validation
policy (and hence no default validation policy). This might be the case
where a DPV server is used as a public server. (The scenario 4 I
mentioned earlier.) Please note that in this extreme case, the client
has
no way to specify any validation policy OID in its request since there
is no any predefined one.  In this extreme case, the client will have to
submit the full set of parameters for path validation ALGORITHM. I
would like to see SCVP to provide an extension mechanism to
let the client submit the full set of parameters for path validation
ALGORITHM. However, please do not confuse "parameters for
validation ALGORITHM" with "parameters for validation POLICY".
Also, please make a clear separation of basic SCVP syntax and
the extension mechanism for submitting parameters for path
validation ALGORITHM.

Wen-Cheng Wang

>
> Trevor,
>
> > Hi Dennis,
> > The OID is optional for the client to use. Servers don't have to
support
> > this.
>
> I disagree. The "RFC 3280 compliantbasic validation policy", i.e the
one
> which only includes basic path validation, with no extra and no
shortcuts,
> as defined by RFC 3280, will have an OID. Since this policy does not
> contains values such as root keys, this validation policy needs
additional
> parameters.
>
> Intelligent clients may use this one and specify parameters.
>
> Thin clients will simply refer to an OID which refers globally to a
> validation algorithm and its parameters.
>
> I have talked to customers and their position is to have flexible
validation
> policies. As an example, some says: if we want to take purposely the
risk
of
> not testing ARLs, it is our choice. The validation policy should not
mandate
> to test ARLs, but if for some validation policies it is adequate to do
so,
> it should be possible to do so.
>
> > It become a matter of mutual agreement between the client and
> > server what the OID represents.
>
> Not necessarilly. Since the OID is not in the arc of the server, it
may be
> defined by anyone. If that definition is separately accessible both to
the
> client and to the server then it can be supported by the server and
the
> client may refer to it. In such a case there is no need for a mutual
agreement.
>
> > An SCVP server must either comply with any request or return an
error
>
> True.
>
>  > so I don't see the validation policy OID
> > needs any special treatment beyond want SCVP already defines.
>
> I don't see the relationship between the true statement above and the
> conclusion.
>
> As already stated on this list, SCVP stands for "Simple", otherwise we
will
> have to drop the "S", and then we would have "CVP". :-|
>
> Denis
>
> > Trevor

Date: Wed, 12 May 2004 20:22:39 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: SCVP & validation policies
Cc: [email-masked]
Sender: [email-masked]

trevor,

Your clients may need to be updated each time you change anything
in the structure of your certs, or in the rules of the policies,

Any code that can be avoided, seems good to me in line with
the requirement for dumb client support.   

> 
> Hi Denis,
> Any software does not have a clue abut most things in life. To operate
> the administrator of the client has to have understand what is going on.
> If the administrator does not understand what the implications of their
> actions are, then they make mistakes. Your premise is that simplified
> administration is only possible in the case of SCVP by the use of the
> OID. Given there is a vast quantity of administration software which his
> able to present simple choices to the administrator while at the same
> time configuring multiple parameters without there knowledge mean this
> is not the case.
> Trevor
> 

Date: Wed, 12 May 2004 20:09:33 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: SCVP & validation policies
Cc: [email-masked]
Sender: [email-masked]

Denis, 

I assume you mean 'minimal' instead of 'standard',
'the standard rerequest for a very dumb client'
 
> This means that any validation specific parameter must *not* be part of
> the standard request.
> 
> Denis

Date: Wed, 12 May 2004 11:45:17 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
Sender: [email-masked]

Denis and Tom,

It is my hope that PI will become an RFC in the near future, so
that certificates (from an un-named large PKI :-) that currently
handle PIs by munging them into Common Name (e.g.,
CN="Kemp.David.P.0514101404") will have a saner alternative.

Comments:

"Assigner Authority and Type" could and should be better explained,
in the I-D / RFC, but it is also clear what it means without such
an explanation.  See www.acq.osd.mil/uid/policy.html,
"Guide to Uniquely Identifying Items" for an example.  The
guide defines five "Issuing Agencies" (assigner authorities)
where each issuing agency defines the type of identifier it
assigns.  The issuing agencies (and types) are:

   1. EAN-International (EAN.UCC company prefix that goes on the
barcode of everything you buy in the supermarket)

   2. Telcordia Technologies (ANSI T1.220 numbers)

   3. Dun & Bradstreet (DUNS number)

   4. Allied Committee 135 (CAGE code - look up your favorite
company's number at www.dlis.dla.mil/cage_welcome.asp)

   5. European Health Industry Business Communications Council
(EHIBCC number)

There should not be a large number of PI assigner authorities,
but there will be more than five and the list will grow, so they
can't be enumerated within the RFC itself.   It is reasonable
to identify them by IANA-assigned value, or by OID.  It is not
completely unreasonable to identify them by URI, but there is
an impedance mismatch between the goals of PI (physical
organizations with stable business processes to establish
reliable identifiers) and the mechanism of URI (put up a
document/resource somewhere in cyberspace).  Not that a URI
couldn't point to a substantial, permanent organization, or
that the target of an OID couldn't be ephemeral, but OIDs
do have a more substantial "flavor" than URIs.

More to the point, an OID tells a machine implementation what
to do with a PI, whereas a URI is presumably intended to cause
the implementation to make an online access to find out what
to do.  That is an unreasonable burden.

I believe that the syntax of PI-08 is fine as is, and that with
Jim Schaad's corrections and perhaps some more explanatory text
the draft is ready to become an RFC.

Dave

Denis Pinkas wrote:
> 
> Anders,
> 
>> Well Jim,
>> The PI-draft is certainly an odd creature that has been in PKIX's
>> "custody" for now close to four(!) years.
>>
>> A few comments to PI in general and some draft-08 specific.
>>
>> Draft-08: identifierType    "The IdentifierType field, when present, 
>> is an OID which identifies    both the Assigner Authority and the type 
>> of that field. It is an OID"
>>
>> The words "type of that field" has never been explained.  But we all
>> know exactly what the authors' mean don't we?  :-|
>>
>> Draft-08: identifierType has, as you noted been reduced to only support
>> OIDs, probably due to the authors' belief that OIDs are more permanent.
> 
> 
> It was not exactly the author's belief, but the IESG belief.
> 
>> However, the rest of the computer industry have no problems using URIs
>> making PI "incompatible" and "deviating".  A URI also have the
>> big advantage that it may point to a document.
> 
> 
>  ... that has then disappeared, or even worse, pointing to a document 
> that is different from the original one.
> 
>> I find this "obsession" with permanence wrong, because if a CA 
>> disappears,
>> its regitered DNS name is taken by somebody else, 
> 
> 
> The URI was to designate an object defined by an Assigner Authority, not 
> by a CA.
> 
>> the certificates are
>> anaway no longer usable and names may indeed be reused. That is, OID 
>> or URI is a
>> deployment issue.  At best you can RECOMMEND the "serious"
>> implementer to use an OID.
>>
>> PI-General: During the PI development serialNumber has become
>> the de-facto standard for keeping a permanent (or static which is
>> really more what we are talking about) identifier.
> 
> 
> You have already made this comment in the past. serialNumber serves a 
> different purpose. Please take a look at RFC 3039 :
> 
>    The serialNumber attribute type SHALL, when present, be used to
>    differentiate between names where the subject field would otherwise
>    be identical.  This attribute has no defined semantics beyond
>    ensuring uniqueness of subject names.
> 
>> Anyway, PI-using relying party software have little reason to
>> bother about PI as the existing systems I know of simply does
>> not "decipher" certificates looking for the most "attractive"
>> name form(?), they just _assume_ that things are as the CP says. Most 
>> of these CAs also obey to Anders' nowadays (in)famous
>>  "best practice CA formula":
>>
>>                    CA <=> Policy
>>
>> which makes identifierType redundant and also eliminating the
>> need for additional Subject name forms like PI.
> 
> 
> If you do not have a need for the PI, then that's fine; but other people 
> may wish to use it, as soon/long as it is defined.
> 
> Denis
> 
> 
> 
>> Anders
>>
>> ----- Original Message ----- From: "Jim Schaad" <[email-masked]>
>> To: "'Denis Pinkas'" <[email-masked]>; "'Tom Gindin'" 
>> <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Thursday, January 22, 2004 03:22
>> Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>
>>
>>
>> Comments on draft -08.
>>
>> 1.  Privacy concerns should be additionally outlined and covered in the
>> security considerations section.
>>
>> 2.  Section 1, para 9: Text here allows for an AA to have a unique URI
>> name.  Has been removed from the syntax.
>>
>> 3.  Section 1, para 14:  Suggested text "both the same permanent
>> identifier value and the same Authority Identifer Value, then these".
>> (I find the use of identityType to be confusing since I consider this to
>> relate to type choice of IdentifierValue as well.)
>>
>> 4.  Section 2:  What is the criteria for use of iA5String vs uTF8String?
>>
>>
>> 5.  Section 2:  When doing comparisons do I need to cross compare these
>> two different value items?
>>
>> 6.  Section 2: The statement 'It is an OID.' is redundant and can be
>> removed.
>>
>> 7.  Section 3: Contains a paragraph dealing with matching rules.  Since
>> this is no longer a field in the structure the paragraph should be
>> re-written to state what the one and only matching rule is.
>>
>> 8.  Appendix A.1:  New request, please put a reference to the document
>> containing the pkix module into the pkix document (i.e. something like
>> "-- found in [RFC 3280]".  This prevents documents from importing
>> modules that are lower in the standards process without having any
>> explicit reference to them.
>>
>> jim
>>
>>
>>
>>> -----Original Message-----
>>> From: [email-masked] 
>>> [mailto:[email-masked]] On Behalf Of 
>>> [email-masked]
>>> Sent: Wednesday, January 21, 2004 1:27 PM
>>> To: IETF-Announce:
>>> Cc: [email-masked]
>>> Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories. This draft is a work item of the Public-Key 
>>> Infrastructure (X.509) Working Group of the IETF.
>>>
>>> Title : Internet X.509 Public Key Infrastructure Permanent Identifier
>>> Author(s) : D. Pinkas, T. Gindin
>>> Filename : draft-ietf-pkix-pi-08.txt
>>> Pages : 12
>>> Date : 2004-1-21
>>>
>>> This document define a new form of name, called permanent identifier, 
>>> that may be included in the subjectAltName extension of a public key 
>>> certificate issued to an entity.
>>> The permanent identifier is an optional feature that may be used by a 
>>> CA to indicate that the certificate relates to the same entity even 
>>> if the name or the affiliation of that entity stored in the subject 
>>> or another name form in the subjectAltName extension has changed.
>>> The subject name, carried in the subject field, is only unique for 
>>> each subject entity certified by the one CA as defined by the issuer 
>>> name field. Also, the new name form can carry a name that is unique 
>>> for each subject entity certified by a CA.
>>>
>>> A URL for this Internet-Draft is: 
>>> http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.txt

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 09:05:56 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Denis,
Any software does not have a clue abut most things in life. To operate
the administrator of the client has to have understand what is going on.
If the administrator does not understand what the implications of their
actions are, then they make mistakes. Your premise is that simplified
administration is only possible in the case of SCVP by the use of the
OID. Given there is a vast quantity of administration software which his
able to present simple choices to the administrator while at the same
time configuring multiple parameters without there knowledge mean this
is not the case.
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2004 12:25 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: SCVP & validation policies

Trevor,

> You also have to understand enough so that the administrative 
> configuration of the client is generating the right kind of request. 
 > > SCVP client is ?only following orders? in many instances and has
from a The SCVP client is "only following orders" in many instances and
has
 > from a perspective no idea if it is the right kind of request, only
if it
 > is well formed to the rules it has been given. Both the administrator
of
> the client and the administrator of the server has to understand in
much 
> grater detail what the given policy is. Once you abstract though the 
> OID, you are placing a greater burden on the OOB admin to admin
process.

The client does not have to "understand" what the validation given
policy is.

The client only needs to know that, for a given application a given OID
for 
the validation policy is needed. He does not need to have a clue of the 
details of the validation policy which may remain fully opaque to him.

This means that any validation specific parameter must *not* be part of
the 
standard request.

Denis

> Trevor
------------------------------------------------------------------------
> 
> From: James Jing [mailto:[email-masked]]
> Sent: Tuesday, May 11, 2004 5:09 PM
> To: Trevor Freeman; [email-masked]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> Agree that the client needs to have all the data in order to build the

> request. However, I think ?understand? is too strong a requirement.
The 
> client may not need to ?understand? the data, some of which may be 
> factors affecting the server only. Perhaps I am too pedantic about the

> word ?understand?.
> 
>  
> 
> Back to indirection, if ?understanding? is not a requirement, then the

> client need not to be aware that an OID is an indirection to a set of 
> policies.
> 
>  
> 
> James
> 
>  
> 
>
------------------------------------------------------------------------
> 
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Wednesday, 12 May 2004 9:49 AM
> To: James Jing; [email-masked]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> The client has to understand what is required to build a request i.e.
> What data does it need to supply to the server. It does not need to be
> aware of the factors which effect the server.
> Trevor
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of James Jing
> Sent: Tuesday, May 11, 2004 4:01 PM
> To: [email-masked]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> I think policy OIDs should remain abstract, or at least can be
abstract.
> That is that there is no requirement for the client software to
> understand the parameters.
> 
> I am more thinking of using SCVP to validate a certificate in the
> context of a transaction, where the policy OID in SCVP might be used
to
> identify such a context to the server.
> 
> For example, a certificate validation request is carried out with
regard
> to the acceptability of the holder's creditworthiness in the context
of
> a credit-based transaction. In this case, the policy OID could be used
> to indicate the class of assuarances that the CA's CSP provides for,
> resulting in the server selecting a subset of acceptable trust
anchors.
> 
> James
> 
>  
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Friday, 7 May 2004 6:28 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>>Hi Steve,
>>If you want to have a shorthand notation for a validation policy,
given
> 
>>we have a finite set of parameters, the I don't see the value of
>>indirection via an OID. Using a hash of the set of inputs provides a
>>way of expressing the same thing without introducing ambiguity of does
>>both parties have a common understating of that this means. At some
>>point someone has to define the policy in terms of the 3280 input
> parameters.
>>That definition is just as applicable and consumable by the client as
a
> 
>>server therefore what did we gain from the shorthand notation? It
would
> 
>>be pretty trivial to define some XML which would allow that set of
>>validation parameters to be imported by any SCVP entity.
>>Trevor
> 
> Trevor,
> 
> It is not indirection via an OID, it is identification via an OID.
> Clients never have to be aware of the parameters if we use an OID, and
> simplification of clients is one of the goals of SCVP. So I cannot
agree
> with your comment that clients have to be able to consume these
> parameters.
> 
> Given that as a basis, it seems that we are debating whether to use
OIDs
> or to create some other form of identifier via hashing parameters. I
> don't see the latter as attractive, since it requires additional
> specification of the canonicalization and encoding of the parameters
to
> ensure consistency in hash computation between client and server.
> 
> Steve
> 
>  
> 
> This e-mail, and any attachments hereto, is intended only for use by
the 
> named addressee(s) and may contain legally privileged and/or 
> confidential information.  If you are not the intended recipient, you 
> are hereby notified that any dissemination, distribution or copying of

> this e-mail, and any attachments hereto, is strictly prohibited.  If
you 
> have received this transmission in error, please notify me immediately

> and permanently delete the original and all copies and printouts of
this 
> e-mail.

Date: Wed, 12 May 2004 14:14:54 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: SCVP & validation policies
Cc: [email-masked]
Sender: [email-masked]

> 
> Hi Peter,
> I think saying the client must validate the ku itself is a big jump, so
> allowing the client to pass lets them choose how must certificate
> processing they perform.
Do you think that it is good, or not?
 
I am not sure that is a good and/or whether this corresponds to the
idea of totally centralized validation, i.e. minimal processing
at the client side.

I tend to say that the client should only be required to
use the public key.

> 
> For the requestor, I don't see any other processing than as binary blob
> is necessary. Therefore if you have an octet string, the server just
> does a binary companies on the data.

This is not conformant with the requirements, the server needs some
way to match the identifiers with the authenticated identities. To me, an
an almost opaque octet string doesn't seem the right approach.
In fact, you don't have a binary blob, since you don't allow zeros,
for example, if a client want to put a hash of something.

I propose the following compromise:

  Identifiers ::= SEQUENCE OF { 
          CHOICE {
               opaqueId OCTET STRING,
               nameId GeneralName
          }

and a statement says that in order to compare for loop detection, a server
will do a comparision of the encoded element (including the tag).

and use this as the type for requestor and responder

From: "Wen-Cheng Wang" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Santoni Adriano" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Steve Hanna" <[email-masked]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String inencodingRDNs
Date: Wed, 12 May 2004 20:07:20 +0800
Sender: [email-masked]

Stefan,

Although I personally prefer to remain it as a 'MUST', but if
PKIX WG majority decide to change it to be a 'SHOULD',
I will accept that.

Another compromise is not to REQUIRE CAs established
before the deadline to migrate to UTF8String encoding. That is,
if an old CA already use PrintableString encoding it can continue
to use PrintableString encoding. One day if the old CA need
perform to key rollover, it is STRONGLY RECOMMENDED (MUST?)
to take that opportunity to migrate to UTF8String encoding.
For CAs established after the deadline, it is STRONGLY
RECOMMENDED (MUST?) to adopt UTF8String encoding
from the beginning. By doing so, I believe that the infrastructure
will ultimately uniform the name encoding.

As for the deadline, since the deadline REQUIRED by RFC 3280
had already been past and it did not come true, a new deadline will
be needed.

Wen-Cheng Wang

> 
> Wen-Cheng,
> 
> I think we agree on the theory parts. No need to repeat them.
> 
> The only disagreement is whether RFC 3280 should REQUIRE UTF-8 where
> printable string is sufficient.
> 
> I think it should not do so. It should limit itself to a recommendation
> (SHOULD)
> 
> RFC 3280 is an important profile, and while it may seem as a voluntary
> profile for many, it is actually something that gets imposed as real
> requirements for others.
> 
> Requiring UTF-8 causes interoperability problems, also among those who
> have faithfully followed RFC 3280, and thus it is a bad requirement.
> 
> I also pledge that name encoding rollover certificates, as specified in
> RFC 3280 is in error and thus has little merit in the real world.
> Migration should thus be allowed in such pase that no name
> encoding-rollover certificates are needed.
> 
> 
> ----
> Except from this I agree that we should try to fix X.509 name matching
> in RFC 3280 name constraining, which is a bug. But that is a separate
> issue.
> 
> /Stefan
> 
> > -----Original Message-----
> > From: Wen-Cheng Wang [mailto:[email-masked]]
> > Sent: den 12 maj 2004 11:11
> > To: Stefan Santesson; Stephen Kent; Santoni Adriano
> > Cc: [email-masked]; [email-masked]; Steve Hanna
> > Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
> > encodingRDNs
> > 
> > > Yes, you can do a lot of cool things in theory.
> > >
> > > The cruel truth is that your name encoding roll-over certs (e.g.
> > > CA1-CA1-p-u-cert) is not self issued according to RFC 3280.
> > 
> > That is why I said that the definition of self-issued certificates in
> RFC
> > 3280 (or maybe its definition in the X.509 standard itself) should
> > be revised or be clarified in son-of-3280 (or in an amendment of
> > the X.509 standard as well).
> > 
> > >
> > > RFC 3280 section 6.1:
> > >    A certificate is self-issued if the DNs that appear in the
> subject
> > >    and issuer fields are identical and are not empty.
> > >
> > > RFC 3280 section 4.1.2.4:
> > >       (a)  attribute values encoded in different types (e.g.,
> > >       PrintableString and BMPString) MAY be assumed to represent
> > >       different strings;
> > 
> > Remenber that RFC 3280 section 4.1.2.4 also said:
> > 
> >    Implementations of this profile are permitted to use the comparison
> >    algorithm defined in the X.500 series.
> > 
> > In that respect, you can not said that name rollover certificates are
> not
> > self-issued.
> > 
> > >
> > > So in current implementations of RFC 3280, many valid certificates
> will
> > > fail after introduction of name rollover certs in the chain, because
> > > path validation will not treat them as self-issued.
> > 
> > I admit that most CURRENT implementations of RFC 3280 path
> > validation will fail to treat name rollover certificates as
> self-issued,
> > but
> > it does not mean that we should not recommend FUTURE revisions
> > of those implementations and new implementations to treat them as
> > self-issued.
> > 
> > >
> > > Further, the name constraint problem persists, adds to this but also
> > > exist regardless of this problem.
> > >
> > > RFC 3280 section 4.2.1.11
> > >    When applying restrictions of the form directoryName, an
> > >    implementation MUST compare DN attributes.  At a minimum,
> > >    implementations MUST perform the DN comparison rules specified in
> > >    Section 4.1.2.4.
> > 
> > That is why I said RFC 3280 path validation algorithm should also be
> > revised.
> > 
> > >
> > > Fixing next version of RFC 3280 to include better name matching
> rules is
> > > a good thing but far from enough to take care of real problems with
> > > current infrastructure.
> > 
> > Fixing next version of RFC 3280 does not magically take care of real
> > problems with current infrastructure, but it encourge current
> > infrastructure
> > to migrate to solve the problems.
> > 
> > >
> > > We have to try to keep in mind what we make all this hassle for!!
> > >
> > > This is NOT about whether we should use UTF-8 or not to accommodate
> > > complex character sets!! This is about what we are prepared to do to
> > > make sure NOTHING is encoded as PrintableString WHEN PrintableString
> is
> > > sufficient.
> > >
> > > This old transition rule was created in RFC 2459 before the modern
> path
> > > validation algorithm was invented and before self-issued
> certificates
> > > was a special case.
> > 
> > That does not mean that name rollover certificates can not solve the
> > mixed name-encoding  problem.
> > 
> > >
> > > Let's just admit that we overlooked this issue when we created RFC
> 3280
> > > and reshaped path validation. It was an understandable human error,
> > > which lead to a defect.
> > 
> > Yes, RFC 3280 indeed overlooked this issue. That is why it should be
> > revised.
> > 
> > >
> > > So let's then also admit that REQUIRING UTF-8 when printableString
> is
> > > sufficient, is not a very good idea when all practical matters are
> > > measured, and that it never should have made it to more than a
> > > RECOMMENDATION.
> > 
> > Isn't it the IETF policy to encourge all new implementations to
> migrate
> > to support UTF-8? The philosophy is that if one encoding is sufficient
> to
> > cover universal characters, why should we recommend two?
> > 
> > >
> > > Whatever we say here, this is a requirement that many implementers
> will
> > > have to ignore for a many years to come.
> > 
> > Conformance to any IETF RFC is all voluntary. No one can enfoce any
> > implementer for that if the implementer chooses to ignore the
> requirement
> > or recommendation of any IETF RFC. RFC 3280 might not have the
> > power to enforce all implementation to migrate to UTF-8 encoding.
> > However, as an IETF RFC, it definitely has a great effect. At least, I
> > see more and more applications can correctly handle certificates with
> > named in UTF-8 encoding. Therefore, I prefer to see son-of-3280 to
> > continue requiring conformant implementations to migrate to UTF-8
> > encoding.
> > 
> > Wen-Cheng Wang
> 
> 

Content-class: urn:content-classes:message
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs
Date: Wed, 12 May 2004 11:24:43 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Santoni Adriano" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Steve Hanna" <[email-masked]>
Sender: [email-masked]

Wen-Cheng,

I think we agree on the theory parts. No need to repeat them.

The only disagreement is whether RFC 3280 should REQUIRE UTF-8 where
printable string is sufficient.

I think it should not do so. It should limit itself to a recommendation
(SHOULD)

RFC 3280 is an important profile, and while it may seem as a voluntary
profile for many, it is actually something that gets imposed as real
requirements for others.

Requiring UTF-8 causes interoperability problems, also among those who
have faithfully followed RFC 3280, and thus it is a bad requirement.

I also pledge that name encoding rollover certificates, as specified in
RFC 3280 is in error and thus has little merit in the real world.
Migration should thus be allowed in such pase that no name
encoding-rollover certificates are needed.

----
Except from this I agree that we should try to fix X.509 name matching
in RFC 3280 name constraining, which is a bug. But that is a separate
issue.

/Stefan

> -----Original Message-----
> From: Wen-Cheng Wang [mailto:[email-masked]]
> Sent: den 12 maj 2004 11:11
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [email-masked]; [email-masked]; Steve Hanna
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
> encodingRDNs
> 
> > Yes, you can do a lot of cool things in theory.
> >
> > The cruel truth is that your name encoding roll-over certs (e.g.
> > CA1-CA1-p-u-cert) is not self issued according to RFC 3280.
> 
> That is why I said that the definition of self-issued certificates in
RFC
> 3280 (or maybe its definition in the X.509 standard itself) should
> be revised or be clarified in son-of-3280 (or in an amendment of
> the X.509 standard as well).
> 
> >
> > RFC 3280 section 6.1:
> >    A certificate is self-issued if the DNs that appear in the
subject
> >    and issuer fields are identical and are not empty.
> >
> > RFC 3280 section 4.1.2.4:
> >       (a)  attribute values encoded in different types (e.g.,
> >       PrintableString and BMPString) MAY be assumed to represent
> >       different strings;
> 
> Remenber that RFC 3280 section 4.1.2.4 also said:
> 
>    Implementations of this profile are permitted to use the comparison
>    algorithm defined in the X.500 series.
> 
> In that respect, you can not said that name rollover certificates are
not
> self-issued.
> 
> >
> > So in current implementations of RFC 3280, many valid certificates
will
> > fail after introduction of name rollover certs in the chain, because
> > path validation will not treat them as self-issued.
> 
> I admit that most CURRENT implementations of RFC 3280 path
> validation will fail to treat name rollover certificates as
self-issued,
> but
> it does not mean that we should not recommend FUTURE revisions
> of those implementations and new implementations to treat them as
> self-issued.
> 
> >
> > Further, the name constraint problem persists, adds to this but also
> > exist regardless of this problem.
> >
> > RFC 3280 section 4.2.1.11
> >    When applying restrictions of the form directoryName, an
> >    implementation MUST compare DN attributes.  At a minimum,
> >    implementations MUST perform the DN comparison rules specified in
> >    Section 4.1.2.4.
> 
> That is why I said RFC 3280 path validation algorithm should also be
> revised.
> 
> >
> > Fixing next version of RFC 3280 to include better name matching
rules is
> > a good thing but far from enough to take care of real problems with
> > current infrastructure.
> 
> Fixing next version of RFC 3280 does not magically take care of real
> problems with current infrastructure, but it encourge current
> infrastructure
> to migrate to solve the problems.
> 
> >
> > We have to try to keep in mind what we make all this hassle for!!
> >
> > This is NOT about whether we should use UTF-8 or not to accommodate
> > complex character sets!! This is about what we are prepared to do to
> > make sure NOTHING is encoded as PrintableString WHEN PrintableString
is
> > sufficient.
> >
> > This old transition rule was created in RFC 2459 before the modern
path
> > validation algorithm was invented and before self-issued
certificates
> > was a special case.
> 
> That does not mean that name rollover certificates can not solve the
> mixed name-encoding  problem.
> 
> >
> > Let's just admit that we overlooked this issue when we created RFC
3280
> > and reshaped path validation. It was an understandable human error,
> > which lead to a defect.
> 
> Yes, RFC 3280 indeed overlooked this issue. That is why it should be
> revised.
> 
> >
> > So let's then also admit that REQUIRING UTF-8 when printableString
is
> > sufficient, is not a very good idea when all practical matters are
> > measured, and that it never should have made it to more than a
> > RECOMMENDATION.
> 
> Isn't it the IETF policy to encourge all new implementations to
migrate
> to support UTF-8? The philosophy is that if one encoding is sufficient
to
> cover universal characters, why should we recommend two?
> 
> >
> > Whatever we say here, this is a requirement that many implementers
will
> > have to ignore for a many years to come.
> 
> Conformance to any IETF RFC is all voluntary. No one can enfoce any
> implementer for that if the implementer chooses to ignore the
requirement
> or recommendation of any IETF RFC. RFC 3280 might not have the
> power to enforce all implementation to migrate to UTF-8 encoding.
> However, as an IETF RFC, it definitely has a great effect. At least, I
> see more and more applications can correctly handle certificates with
> named in UTF-8 encoding. Therefore, I prefer to see son-of-3280 to
> continue requiring conformant implementations to migrate to UTF-8
> encoding.
> 
> Wen-Cheng Wang

From: "Wen-Cheng Wang" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Trevor Freeman" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: Re: SCVP & validation policies
Date: Wed, 12 May 2004 17:20:37 +0800
Sender: [email-masked]

I would like to support that even the validation policy OID itself is
optional for the client to use. As I stated in my earlier post, if a client
fully trust the validation server, then it might not have to specify a
validation policy OID in its request. In that case, it means that the
client trusts the validation server to adopt the default validation policy
predefinied by the management authority of the application domain
(such as an enterprise). For example, in scenario 1 and scenario 3 I
mentioned in my earlier post, if the client request does not specify any
validation policy OID, then server will adopt the default validation
policy. For you reference, scenario 1 and scenario 3 are as follows:

Scenario 1 (single central-managed vlidation policy)

  DPV server:
      only supports a single central-managed vlidation policy
      the validation policy implies all policy-dependent parameters

  DPV client:
      the validation request may optionally specify the vlidation policy OID
      the validation request needs not specify any policy-dependent
          parameters

Scenario 3 (multiple central-managed vlidation policies with a default
validation policy)

  DPV server:
      supports multiple central-managed vlidation policies with one of them
          is the default
      each validation policy implies its policy-dependent parameters

  DPV client:
      the validation request should specify the vlidation policy OID
      if the request did not specify the vlidation policy OID, then the
         server will use the default one
      the validation request needs not to specify any policy-dependent
         parameters

These are the simplest cases of the use of DPV protocol. I hope that
basic SCVP syntax should support these simplest cases more clearly.
(I mean that the ambiguity in the current syntax should be reduced.)

In contrast to these simplest cases, an extreme case of the use of
DPV protocol is the case where there is no any predefined validation
policy (and hence no default validation policy). This might be the case
where a DPV server is used as a public server. (The scenario 4 I
mentioned earlier.) Please note that in this extreme case, the client has
no way to specify any validation policy OID in its request since there
is no any predefined one.  In this extreme case, the client will have to
submit the full set of parameters for path validation ALGORITHM. I
would like to see SCVP to provide an extension mechanism to
let the client submit the full set of parameters for path validation
ALGORITHM. However, please do not confuse "parameters for
validation ALGORITHM" with "parameters for validation POLICY".
Also, please make a clear separation of basic SCVP syntax and
the extension mechanism for submitting parameters for path
validation ALGORITHM.

Wen-Cheng Wang

>
> Trevor,
>
> > Hi Dennis,
> > The OID is optional for the client to use. Servers don't have to support
> > this.
>
> I disagree. The "RFC 3280 compliantbasic validation policy", i.e the one
> which only includes basic path validation, with no extra and no shortcuts,
> as defined by RFC 3280, will have an OID. Since this policy does not
> contains values such as root keys, this validation policy needs additional
> parameters.
>
> Intelligent clients may use this one and specify parameters.
>
> Thin clients will simply refer to an OID which refers globally to a
> validation algorithm and its parameters.
>
> I have talked to customers and their position is to have flexible
validation
> policies. As an example, some says: if we want to take purposely the risk
of
> not testing ARLs, it is our choice. The validation policy should not
mandate
> to test ARLs, but if for some validation policies it is adequate to do so,
> it should be possible to do so.
>
> > It become a matter of mutual agreement between the client and
> > server what the OID represents.
>
> Not necessarilly. Since the OID is not in the arc of the server, it may be
> defined by anyone. If that definition is separately accessible both to the
> client and to the server then it can be supported by the server and the
> client may refer to it. In such a case there is no need for a mutual
agreement.
>
> > An SCVP server must either comply with any request or return an error
>
> True.
>
>  > so I don't see the validation policy OID
> > needs any special treatment beyond want SCVP already defines.
>
> I don't see the relationship between the true statement above and the
> conclusion.
>
> As already stated on this list, SCVP stands for "Simple", otherwise we
will
> have to drop the "S", and then we would have "CVP". :-|
>
> Denis
>
> > Trevor

From: "Wen-Cheng Wang" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Santoni Adriano" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Steve Hanna" <[email-masked]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs
Date: Wed, 12 May 2004 17:10:35 +0800
Sender: [email-masked]

> Yes, you can do a lot of cool things in theory.
>
> The cruel truth is that your name encoding roll-over certs (e.g.
> CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

That is why I said that the definition of self-issued certificates in RFC
3280 (or maybe its definition in the X.509 standard itself) should
be revised or be clarified in son-of-3280 (or in an amendment of
the X.509 standard as well).

>
> RFC 3280 section 6.1:
>    A certificate is self-issued if the DNs that appear in the subject
>    and issuer fields are identical and are not empty.
>
> RFC 3280 section 4.1.2.4:
>       (a)  attribute values encoded in different types (e.g.,
>       PrintableString and BMPString) MAY be assumed to represent
>       different strings;

Remenber that RFC 3280 section 4.1.2.4 also said:

   Implementations of this profile are permitted to use the comparison
   algorithm defined in the X.500 series.

In that respect, you can not said that name rollover certificates are not
self-issued.

>
> So in current implementations of RFC 3280, many valid certificates will
> fail after introduction of name rollover certs in the chain, because
> path validation will not treat them as self-issued.

I admit that most CURRENT implementations of RFC 3280 path
validation will fail to treat name rollover certificates as self-issued, but
it does not mean that we should not recommend FUTURE revisions
of those implementations and new implementations to treat them as
self-issued.

>
> Further, the name constraint problem persists, adds to this but also
> exist regardless of this problem.
>
> RFC 3280 section 4.2.1.11
>    When applying restrictions of the form directoryName, an
>    implementation MUST compare DN attributes.  At a minimum,
>    implementations MUST perform the DN comparison rules specified in
>    Section 4.1.2.4.

That is why I said RFC 3280 path validation algorithm should also be
revised.

>
> Fixing next version of RFC 3280 to include better name matching rules is
> a good thing but far from enough to take care of real problems with
> current infrastructure.

Fixing next version of RFC 3280 does not magically take care of real
problems with current infrastructure, but it encourge current infrastructure
to migrate to solve the problems.

>
> We have to try to keep in mind what we make all this hassle for!!
>
> This is NOT about whether we should use UTF-8 or not to accommodate
> complex character sets!! This is about what we are prepared to do to
> make sure NOTHING is encoded as PrintableString WHEN PrintableString is
> sufficient.
>
> This old transition rule was created in RFC 2459 before the modern path
> validation algorithm was invented and before self-issued certificates
> was a special case.

That does not mean that name rollover certificates can not solve the
mixed name-encoding  problem.

>
> Let's just admit that we overlooked this issue when we created RFC 3280
> and reshaped path validation. It was an understandable human error,
> which lead to a defect.

Yes, RFC 3280 indeed overlooked this issue. That is why it should be
revised.

>
> So let's then also admit that REQUIRING UTF-8 when printableString is
> sufficient, is not a very good idea when all practical matters are
> measured, and that it never should have made it to more than a
> RECOMMENDATION.

Isn't it the IETF policy to encourge all new implementations to migrate
to support UTF-8? The philosophy is that if one encoding is sufficient to
cover universal characters, why should we recommend two?

>
> Whatever we say here, this is a requirement that many implementers will
> have to ignore for a many years to come.

Conformance to any IETF RFC is all voluntary. No one can enfoce any
implementer for that if the implementer chooses to ignore the requirement
or recommendation of any IETF RFC. RFC 3280 might not have the
power to enforce all implementation to migrate to UTF-8 encoding.
However, as an IETF RFC, it definitely has a great effect. At least, I
see more and more applications can correctly handle certificates with
named in UTF-8 encoding. Therefore, I prefer to see son-of-3280 to
continue requiring conformant implementations to migrate to UTF-8
encoding.

Wen-Cheng Wang

From: Santoni Adriano <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>
Cc: [email-masked], [email-masked], Steve Hanna <[email-masked]>, Wen-Cheng Wang <[email-masked]>, Stephen Kent <[email-masked]>
Subject: R: R: I: R: RFC3280: doubt on the use of UTF8String in encoding R DNs
Date: Wed, 12 May 2004 10:39:27 +0200
Sender: [email-masked]

Thank you for this additional contribution.

"So let's then also admit that REQUIRING UTF-8 when printableString is
sufficient, is not a very good idea when all practical matters are measured,
..."

This is exactly the point, IMHO. UTF-8 is a clever encoding, probably the
best when we CAs have to put names like "Papadopulos" or "Wen-Cheng Wang"
into a certificate in its original and "true" character set.

"...and that it never should have made it to more than a RECOMMENDATION."

This sounds very sensible. I buy it!

Adriano

-----Messaggio originale-----
Da: Stefan Santesson [mailto:[email-masked]] 
Inviato: martedì 11 maggio 2004 15.33
A: Wen-Cheng Wang; Stephen Kent; Santoni Adriano
Cc: [email-masked]; [email-masked]; Steve Hanna
Oggetto: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs

Yes, you can do a lot of cool things in theory.

The cruel truth is that your name encoding roll-over certs (e.g.
CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

RFC 3280 section 6.1:
   A certificate is self-issued if the DNs that appear in the subject
   and issuer fields are identical and are not empty. 

RFC 3280 section 4.1.2.4:
      (a)  attribute values encoded in different types (e.g.,
      PrintableString and BMPString) MAY be assumed to represent
      different strings;

So in current implementations of RFC 3280, many valid certificates will fail
after introduction of name rollover certs in the chain, because path
validation will not treat them as self-issued.

Further, the name constraint problem persists, adds to this but also exist
regardless of this problem.

RFC 3280 section 4.2.1.11
   When applying restrictions of the form directoryName, an
   implementation MUST compare DN attributes.  At a minimum,
   implementations MUST perform the DN comparison rules specified in
   Section 4.1.2.4.

Fixing next version of RFC 3280 to include better name matching rules is a
good thing but far from enough to take care of real problems with current
infrastructure.

We have to try to keep in mind what we make all this hassle for!!

This is NOT about whether we should use UTF-8 or not to accommodate complex
character sets!! This is about what we are prepared to do to make sure
NOTHING is encoded as PrintableString WHEN PrintableString is sufficient.

This old transition rule was created in RFC 2459 before the modern path
validation algorithm was invented and before self-issued certificates was a
special case.

Let's just admit that we overlooked this issue when we created RFC 3280 and
reshaped path validation. It was an understandable human error, which lead
to a defect.

So let's then also admit that REQUIRING UTF-8 when printableString is
sufficient, is not a very good idea when all practical matters are measured,
and that it never should have made it to more than a RECOMMENDATION.

Whatever we say here, this is a requirement that many implementers will have
to ignore for a many years to come.

Stefan Santesson
Program Manager, Windows Security
> -----Original Message-----
> From: Wen-Cheng Wang [mailto:[email-masked]]
> Sent: den 7 maj 2004 04:29
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [email-masked]; [email-masked]; Steve Hanna
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> I do'nt see why name rollover certificates can not solve the mixed 
> encoding problem if the definition of a self-issued certificate and 
> the path validation algorithm in RFC 3280 is revised?
> 
> Let me use an example to explain this.
> 
> Suppose the original certificate chain is:
> 
>    Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert
> 
> where "p-p" means "issuer name in PrintableString" and "subject name 
> in PrintableString".
> 
> Suppose CA2 take the name rollover, it will issue the following two 
> self-issued certificates:
>          CA2-CA2-p-u-cert
>              (i.e., issuer name in PrintableString,
>                      subject name in UTF8String)
>          CA2-CA2-u-p-cert
>              (i.e., issuer name in UTF8String,
>                      subject name in PrintableString)
> 
> Suppose CA1 also take the name rollover, it will issue
> the following two self-issued certificates:
>          CA1-CA1-p-u-cert
>              (i.e., issuer name in PrintableString,
>                      subject name in UTF8String)
>          CA1-CA1-u-p-cert
>              (i.e., issuer name in UTF8String,
>                      subject name in PrintableString)
> 
> Suppose CA2 start to issue EE certificate with UTF8String encoding, 
> and it issues the following EE certificate:
>          CA2-EE2-u-u-cert
> 
> Then,
> EE1 can still be reached by the original certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert
> 
> EE1 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA1-u-p-cert CA1-CA2-p-p-cert
>          CA2-EE1-p-p-cert
> (Assume there is another CA issues a cross-certificate to CA1 in 
> UTF8String encoding.)
> 
> EE2 can be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-p-p-cert CA2-CA2-p-u-cert
>          CA2-EE2-u-u-cert
> 
> One day, if CA1 renews the cross-certificate to CA2 and adopts 
> UTF8String encoding in the new cross-certificate, it will issue the 
> following cross-certificate:
>          CA1-CA2-u-u-cert
> 
> Then,
> EE1 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA1-p-u-cert CA1-CA2-u-u-cert
>          CA2-CA2-u-p-cert CA2-EE1-p-p-cert
> 
> EE2 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-u-u-cert CA2-EE2-u-u-cert
> 
> As you can see, in theory you can always find at least one certificate 
> chain to EE1 (i.e., old cert with PrintableString) or EE2 (i.e., new
cert
> with UTF8String). However, as I said before, we should discuss how to 
> amend RFC 3280 to support such certificate chaining.
> 
> Wen-Cheng Wang
> 
> ----- Original Message -----
> From: "Stefan Santesson" <[email-masked]>
> To: "Wen-Cheng Wang" <[email-masked]>; "Stephen Kent"
<[email-masked]>;
> "Santoni Adriano" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, May 06, 2004 9:32 PM
> Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> >
> > Name rollover certificates only takes care of CA name changes. It 
> > doesn't solve the problem if subject names have mixed encoding in
the
> > forest of user certificates, while the CAs names are intact.
> >
> > Neither does it solve when the constraint is placed above the CA 
> > rollover.
> >
> > Finally, CA name rollover will most likely bust path validation
using
> > other constraining mechanisms because they may just not be
recognized as
> > self issued due to different name encoding.
> >
> > Stefan Santesson
> > Program Manager, Windows Security
> >

*******************Internet Email Confidentiality Footer******************* 
Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi
allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto
erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne
comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso
e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente
messaggio nonche' nei suoi eventuali allegati devono essere attribuite
esclusivamente al mittente e non possono essere considerate come trasmesse o
autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA
S.p.A. nei confronti del destinatario o di terzi. 
SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of SIA. Besides, The contents
of this message shall be understood as neither given nor endorsed by SIA
S.p.A.. 
SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof. 

Date: Wed, 12 May 2004 09:25:28 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
Subject: Re: SCVP & validation policies
Sender: [email-masked]

Trevor,

> You also have to understand enough so that the administrative 
> configuration of the client is generating the right kind of request. 
 > > SCVP client is ?only following orders? in many instances and has from a The SCVP client is “only following orders” in many instances and has
 > from a perspective no idea if it is the right kind of request, only if it
 > is well formed to the rules it has been given. Both the administrator of
> the client and the administrator of the server has to understand in much 
> grater detail what the given policy is. Once you abstract though the 
> OID, you are placing a greater burden on the OOB admin to admin process.

The client does not have to "understand" what the validation given policy is.

The client only needs to know that, for a given application a given OID for 
the validation policy is needed. He does not need to have a clue of the 
details of the validation policy which may remain fully opaque to him.

This means that any validation specific parameter must *not* be part of the 
standard request.

Denis

> Trevor
> 
>  
> 
> ------------------------------------------------------------------------
> 
> From: James Jing [mailto:[email-masked]]
> Sent: Tuesday, May 11, 2004 5:09 PM
> To: Trevor Freeman; [email-masked]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> Agree that the client needs to have all the data in order to build the 
> request. However, I think ?understand? is too strong a requirement. The 
> client may not need to ?understand? the data, some of which may be 
> factors affecting the server only. Perhaps I am too pedantic about the 
> word ?understand?.
> 
>  
> 
> Back to indirection, if ?understanding? is not a requirement, then the 
> client need not to be aware that an OID is an indirection to a set of 
> policies.
> 
>  
> 
> James
> 
>  
> 
> ------------------------------------------------------------------------
> 
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Wednesday, 12 May 2004 9:49 AM
> To: James Jing; [email-masked]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> The client has to understand what is required to build a request i.e.
> What data does it need to supply to the server. It does not need to be
> aware of the factors which effect the server.
> Trevor
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of James Jing
> Sent: Tuesday, May 11, 2004 4:01 PM
> To: [email-masked]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> I think policy OIDs should remain abstract, or at least can be abstract.
> That is that there is no requirement for the client software to
> understand the parameters.
> 
> I am more thinking of using SCVP to validate a certificate in the
> context of a transaction, where the policy OID in SCVP might be used to
> identify such a context to the server.
> 
> For example, a certificate validation request is carried out with regard
> to the acceptability of the holder's creditworthiness in the context of
> a credit-based transaction. In this case, the policy OID could be used
> to indicate the class of assuarances that the CA's CSP provides for,
> resulting in the server selecting a subset of acceptable trust anchors.
> 
> James
> 
>  
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Friday, 7 May 2004 6:28 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>>Hi Steve,
>>If you want to have a shorthand notation for a validation policy, given
> 
>>we have a finite set of parameters, the I don't see the value of
>>indirection via an OID. Using a hash of the set of inputs provides a
>>way of expressing the same thing without introducing ambiguity of does
>>both parties have a common understating of that this means. At some
>>point someone has to define the policy in terms of the 3280 input
> parameters.
>>That definition is just as applicable and consumable by the client as a
> 
>>server therefore what did we gain from the shorthand notation? It would
> 
>>be pretty trivial to define some XML which would allow that set of
>>validation parameters to be imported by any SCVP entity.
>>Trevor
> 
> Trevor,
> 
> It is not indirection via an OID, it is identification via an OID.
> Clients never have to be aware of the parameters if we use an OID, and
> simplification of clients is one of the goals of SCVP. So I cannot agree
> with your comment that clients have to be able to consume these
> parameters.
> 
> Given that as a basis, it seems that we are debating whether to use OIDs
> or to create some other form of identifier via hashing parameters. I
> don't see the latter as attractive, since it requires additional
> specification of the canonicalization and encoding of the parameters to
> ensure consistency in hash computation between client and server.
> 
> Steve
> 
>  
> 
> This e-mail, and any attachments hereto, is intended only for use by the 
> named addressee(s) and may contain legally privileged and/or 
> confidential information.  If you are not the intended recipient, you 
> are hereby notified that any dissemination, distribution or copying of 
> this e-mail, and any attachments hereto, is strictly prohibited.  If you 
> have received this transmission in error, please notify me immediately 
> and permanently delete the original and all copies and printouts of this 
> e-mail.
> 

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 18:05:29 -0700
From: "Trevor Freeman" <[email-masked]>
To: "James Jing" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-a742e905-c6e4-4c09-8d0f-2771da0c3bda
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C437BD.33B87440"

------_=_NextPart_001_01C437BD.33B87440
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

You also have to understand enough so that the administrative
configuration of the client is generating the right kind of request. The
SCVP client is "only following orders" in many instances and has from a
perspective no idea if it is the right kind of request, only if it is
well formed to the rules it has been given. Both the administrator of
the client and the administrator of the server has to understand in much
grater detail what the given policy is. Once you abstract though the
OID, you are placing a greater burden on the OOB admin to admin process.

Trevor

=20

________________________________

From: James Jing [mailto:[email-masked]]=20
Sent: Tuesday, May 11, 2004 5:09 PM
To: Trevor Freeman; [email-masked]
Subject: RE: SCVP & validation policies

=20

Agree that the client needs to have all the data in order to build the
request. However, I think "understand" is too strong a requirement. The
client may not need to "understand" the data, some of which may be
factors affecting the server only. Perhaps I am too pedantic about the
word "understand".

=20

Back to indirection, if "understanding" is not a requirement, then the
client need not to be aware that an OID is an indirection to a set of
policies.

=20

James

=20

________________________________

From: Trevor Freeman [mailto:[email-masked]]=20
Sent: Wednesday, 12 May 2004 9:49 AM
To: James Jing; [email-masked]
Subject: RE: SCVP & validation policies

=20

The client has to understand what is required to build a request i.e.=20
What data does it need to supply to the server. It does not need to be=20
aware of the factors which effect the server.=20
Trevor=20

-----Original Message-----=20
From: [email-masked] [mailto:[email-masked]]

On Behalf Of James Jing=20
Sent: Tuesday, May 11, 2004 4:01 PM=20
To: [email-masked]=20
Subject: RE: SCVP & validation policies=20

=20

I think policy OIDs should remain abstract, or at least can be abstract.

That is that there is no requirement for the client software to=20
understand the parameters.=20

I am more thinking of using SCVP to validate a certificate in the=20
context of a transaction, where the policy OID in SCVP might be used to=20
identify such a context to the server.=20

For example, a certificate validation request is carried out with regard

to the acceptability of the holder's creditworthiness in the context of=20
a credit-based transaction. In this case, the policy OID could be used=20
to indicate the class of assuarances that the CA's CSP provides for,=20
resulting in the server selecting a subset of acceptable trust anchors.=20

James=20

=20

-----Original Message-----=20
From: Stephen Kent [mailto:[email-masked]]=20
Sent: Friday, 7 May 2004 6:28 AM=20
To: Trevor Freeman=20
Cc: [email-masked]=20
Subject: RE: SCVP & validation policies=20

=20

At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:=20
>Hi Steve,=20
>If you want to have a shorthand notation for a validation policy, given

>we have a finite set of parameters, the I don't see the value of=20
>indirection via an OID. Using a hash of the set of inputs provides a=20
>way of expressing the same thing without introducing ambiguity of does=20
>both parties have a common understating of that this means. At some=20
>point someone has to define the policy in terms of the 3280 input=20
parameters.=20
>That definition is just as applicable and consumable by the client as a

>server therefore what did we gain from the shorthand notation? It would

>be pretty trivial to define some XML which would allow that set of=20
>validation parameters to be imported by any SCVP entity.=20
>Trevor=20

Trevor,=20

It is not indirection via an OID, it is identification via an OID.=20
Clients never have to be aware of the parameters if we use an OID, and=20
simplification of clients is one of the goals of SCVP. So I cannot agree

with your comment that clients have to be able to consume these=20
parameters.=20

Given that as a basis, it seems that we are debating whether to use OIDs

or to create some other form of identifier via hashing parameters. I=20
don't see the latter as attractive, since it requires additional=20
specification of the canonicalization and encoding of the parameters to=20
ensure consistency in hash computation between client and server.=20

Steve=20

=20

This e-mail, and any attachments hereto, is intended only for use by the
named addressee(s) and may contain legally privileged and/or
confidential information.  If you are not the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this e-mail, and any attachments hereto, is strictly prohibited.  If you
have received this transmission in error, please notify me immediately
and permanently delete the original and all copies and printouts of this
e-mail.

------_=_NextPart_001_01C437BD.33B87440
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 11 (filtered)">
<title>RE: SCVP &amp; validation policies</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	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:blue;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p
	{margin-right:0pt;
	margin-left:0pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle19
	{font-family:Arial;
	color:navy;}
span.EmailStyle20
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>You also have to understand enough =
so that
the administrative configuration of the client is generating the right =
kind of
request. The SCVP client is &#8220;only following orders&#8221; in many =
instances
and has from a perspective no idea if it is the right kind of request, =
only if
it is well formed to the rules it has been given. Both the administrator =
of the
client and the administrator of the server has to understand in much =
grater
detail what the given policy is. Once you abstract though the OID, you =
are
placing a greater burden on the OOB admin to admin =
process.</span></font></p>

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

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> James =
Jing
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, May 11, =
2004 5:09
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Trevor Freeman; =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: SCVP &amp; =
validation
policies</span></font></p>

</div>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-AU
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Agree that the =
client
needs to have all the data in order to build the request. However, I =
think
&#8220;understand&#8221; is too strong a requirement. The client may not =
need
to &#8220;understand&#8221; the data, some of which may be factors =
affecting
the server only. Perhaps I am too pedantic about the word
&#8220;understand&#8221;.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-AU
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-AU
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Back to =
indirection, if
&#8220;understanding&#8221; is not a requirement, then the client need =
not to
be aware that an OID is an indirection to a set of =
policies.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-AU
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-AU
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>James</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-AU
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Trevor Freeman [mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, 12 May =
2004 9:49
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> James Jing; =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: SCVP &amp; =
validation
policies</span></font></p>

</div>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>The
client has to understand what is required to build a request =
i.e.</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>What =
data does it
need to supply to the server. It does not need to be</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>aware of the
factors which effect the server.</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Trevor</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>From: [email-masked]
[<a =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>On =
Behalf Of
James Jing</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Sent: Tuesday,
May 11, 2004 4:01 PM</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>To: =
[email-masked]</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Subject: RE: SCVP
&amp; validation policies</span></font><span lang=3DEN-AU> </span></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>I
think policy OIDs should remain abstract, or at least can be =
abstract.</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>That =
is that
there is no requirement for the client software to</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>understand the
parameters.</span></font><span lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>I
am more thinking of using SCVP to validate a certificate in =
the</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>context of a
transaction, where the policy OID in SCVP might be used =
to</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>identify such a
context to the server. </span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>For
example, a certificate validation request is carried out with =
regard</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>to =
the
acceptability of the holder's creditworthiness in the context =
of</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>a =
credit-based
transaction. In this case, the policy OID could be =
used</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>to =
indicate the
class of assuarances that the CA's CSP provides for,</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>resulting in the
server selecting a subset of acceptable trust =
anchors.</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>James</span></font><span
lang=3DEN-AU> </span></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>From: Stephen
Kent [<a href=3D"mailto:[email-masked]">mailto:[email-masked]</a>] =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Sent: Friday, 7
May 2004 6:28 AM</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>To: =
Trevor Freeman</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>Cc: =
[email-masked]</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Subject: RE: SCVP
&amp; validation policies</span></font><span lang=3DEN-AU> </span></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>At
12:10 PM -0700 5/6/04, Trevor Freeman wrote:</span></font><span =
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;Hi Steve,</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;If you want
to have a shorthand notation for a validation policy, =
given</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;we
have a finite set of parameters, the I don't see the value of =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;indirection
via an OID. Using a hash of the set of inputs provides a =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;way of
expressing the same thing without introducing ambiguity of does =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;both parties
have a common understating of that this means. At some =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;point someone
has to define the policy in terms of the 3280 input</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>parameters.</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;That
definition is just as applicable and consumable by the client as =
a</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;server
therefore what did we gain from the shorthand notation? It =
would</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;be
pretty trivial to define some XML which would allow that set of =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;validation
parameters to be imported by any SCVP entity.</span></font><span =
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;Trevor</span></font><span lang=3DEN-AU> =
</span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Trevor</span></font><font
size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>,</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>It
is not indirection via an OID, it is identification via an OID. =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Clients never
have to be aware of the parameters if we use an OID, =
and</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>simplification of
clients is one of the goals of SCVP. So I cannot =
agree</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>with =
your comment
that clients have to be able to consume these</span></font><span =
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>parameters.</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Given
that as a basis, it seems that we are debating whether to use =
OIDs</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>or =
to create some
other form of identifier via hashing parameters. I</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>don't see the
latter as attractive, since it requires additional</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>specification of
the canonicalization and encoding of the parameters =
to</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>ensure consistency
in hash computation between client and server.</span></font><span =
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Steve</span></font><span
lang=3DEN-AU> </span></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>This
e-mail, and any attachments hereto, is intended only for use by the =
named
addressee(s) and may contain legally privileged and/or confidential
information.&nbsp; If you are not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this e-mail, =
and
any attachments hereto, is strictly prohibited.&nbsp; If you have =
received this
transmission in error, please notify me immediately and permanently =
delete the
original and all copies and printouts of this e-mail.</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C437BD.33B87440--

------=_NextPartTM-000-a742e905-c6e4-4c09-8d0f-2771da0c3bda--

content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 10:08:47 +1000
From: "James Jing" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C437B5.4BDF985F
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Agree that the client needs to have all the data in order to build the
request. However, I think "understand" is too strong a requirement. The
client may not need to "understand" the data, some of which may be
factors affecting the server only. Perhaps I am too pedantic about the
word "understand".

=20

Back to indirection, if "understanding" is not a requirement, then the
client need not to be aware that an OID is an indirection to a set of
policies.

=20

James

=20

  _____ =20

From: Trevor Freeman [mailto:[email-masked]]=20
Sent: Wednesday, 12 May 2004 9:49 AM
To: James Jing; [email-masked]
Subject: RE: SCVP & validation policies

=20

The client has to understand what is required to build a request i.e.=20
What data does it need to supply to the server. It does not need to be=20
aware of the factors which effect the server.=20
Trevor=20

-----Original Message-----=20
From: [email-masked] [mailto:[email-masked]]

On Behalf Of James Jing=20
Sent: Tuesday, May 11, 2004 4:01 PM=20
To: [email-masked]=20
Subject: RE: SCVP & validation policies=20

=20

I think policy OIDs should remain abstract, or at least can be abstract.

That is that there is no requirement for the client software to=20
understand the parameters.=20

I am more thinking of using SCVP to validate a certificate in the=20
context of a transaction, where the policy OID in SCVP might be used to=20
identify such a context to the server.=20

For example, a certificate validation request is carried out with regard

to the acceptability of the holder's creditworthiness in the context of=20
a credit-based transaction. In this case, the policy OID could be used=20
to indicate the class of assuarances that the CA's CSP provides for,=20
resulting in the server selecting a subset of acceptable trust anchors.=20

James=20

=20

-----Original Message-----=20
From: Stephen Kent [mailto:[email-masked]]=20
Sent: Friday, 7 May 2004 6:28 AM=20
To: Trevor Freeman=20
Cc: [email-masked]=20
Subject: RE: SCVP & validation policies=20

=20

At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:=20
>Hi Steve,=20
>If you want to have a shorthand notation for a validation policy, given

>we have a finite set of parameters, the I don't see the value of=20
>indirection via an OID. Using a hash of the set of inputs provides a=20
>way of expressing the same thing without introducing ambiguity of does=20
>both parties have a common understating of that this means. At some=20
>point someone has to define the policy in terms of the 3280 input=20
parameters.=20
>That definition is just as applicable and consumable by the client as a

>server therefore what did we gain from the shorthand notation? It would

>be pretty trivial to define some XML which would allow that set of=20
>validation parameters to be imported by any SCVP entity.=20
>Trevor=20

Trevor,=20

It is not indirection via an OID, it is identification via an OID.=20
Clients never have to be aware of the parameters if we use an OID, and=20
simplification of clients is one of the goals of SCVP. So I cannot agree

with your comment that clients have to be able to consume these=20
parameters.=20

Given that as a basis, it seems that we are debating whether to use OIDs

or to create some other form of identifier via hashing parameters. I=20
don't see the latter as attractive, since it requires additional=20
specification of the canonicalization and encoding of the parameters to=20
ensure consistency in hash computation between client and server.=20

Steve=20

=20

This e-mail, and any attachments hereto, is intended only for use by the
named addressee(s) and may contain legally privileged and/or
confidential information.  If you are not the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this e-mail, and any attachments hereto, is strictly prohibited.  If you
have received this transmission in error, please notify me immediately
and permanently delete the original and all copies and printouts of this
e-mail.

------_=_NextPart_001_01C437B5.4BDF985F
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: SCVP &amp; validation policies</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* 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:blue;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-AU link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Agree that the client needs to have =
all
the data in order to build the request. However, I think =
&#8220;understand&#8221;
is too strong a requirement. The client may not need to =
&#8220;understand&#8221;
the data, some of which may be factors affecting the server only. =
Perhaps I am
too pedantic about the word =
&#8220;understand&#8221;.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Back to indirection, if =
&#8220;understanding&#8221;
is not a requirement, then the client need not to be aware that an OID =
is an
indirection to a set of policies.<o:p></o:p></span></font></p>

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

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

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
Trevor Freeman [mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, 12 May =
2004 9:49
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> James Jing; =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: SCVP &amp; =
validation
policies</span></font><span lang=3DEN-US><o:p></o:p></span></p>

</div>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>The
client has to understand what is required to build a request =
i.e.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>What data does it need =
to supply to
the server. It does not need to be</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>aware of the factors =
which effect
the server.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Trevor</span></font> =
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>From: =
[email-masked]
[<a =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>On Behalf Of James =
Jing</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Tuesday, May 11, =
2004 4:01 PM</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: RE: SCVP &amp; =
validation
policies</span></font> <o:p></o:p></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>I think
policy OIDs should remain abstract, or at least can be =
abstract.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>That is that there is no
requirement for the client software to</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>understand the =
parameters.</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>I am more
thinking of using SCVP to validate a certificate in the</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>context of a =
transaction, where the
policy OID in SCVP might be used to</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>identify such a context =
to the
server. </span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>For
example, a certificate validation request is carried out with =
regard</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>to the acceptability of =
the
holder's creditworthiness in the context of</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>a credit-based =
transaction. In this
case, the policy OID could be used</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>to indicate the class of
assuarances that the CA's CSP provides for,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>resulting in the server =
selecting a
subset of acceptable trust anchors.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>James</span></font>
<o:p></o:p></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>From: Stephen Kent [<a
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>] </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Friday, 7 May 2004 =
6:28 AM</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: Trevor =
Freeman</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Cc: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: RE: SCVP &amp; =
validation
policies</span></font> <o:p></o:p></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>At 12:10
PM -0700 5/6/04, Trevor Freeman wrote:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Hi =
Steve,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;If you want to have =
a shorthand
notation for a validation policy, given</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;we
have a finite set of parameters, the I don't see the value of =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;indirection via an =
OID. Using a
hash of the set of inputs provides a </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;way of expressing =
the same
thing without introducing ambiguity of does </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;both parties have a =
common
understating of that this means. At some </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;point someone has to =
define the
policy in terms of the 3280 input</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>parameters.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;That definition is =
just as
applicable and consumable by the client as a</span></font> =
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;server
therefore what did we gain from the shorthand notation? It =
would</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;be
pretty trivial to define some XML which would allow that set of =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;validation =
parameters to be
imported by any SCVP entity.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Trevor</span></font> =
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Trevor,</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>It is not
indirection via an OID, it is identification via an OID. =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>Clients never have to be =
aware of
the parameters if we use an OID, and</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>simplification of =
clients is one of
the goals of SCVP. So I cannot agree</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>with your comment that =
clients have
to be able to consume these</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>parameters.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Given
that as a basis, it seems that we are debating whether to use =
OIDs</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>or to create some other =
form of
identifier via hashing parameters. I</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>don't see the latter as =
attractive,
since it requires additional</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>specification of the
canonicalization and encoding of the parameters to</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>ensure consistency in =
hash
computation between client and server.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Steve</span></font>
<o:p></o:p></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>This
e-mail, and any attachments hereto, is intended only for use by the =
named
addressee(s) and may contain legally privileged and/or confidential
information.&nbsp; If you are not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this e-mail, =
and
any attachments hereto, is strictly prohibited.&nbsp; If you have =
received this
transmission in error, please notify me immediately and permanently =
delete the
original and all copies and printouts of this =
e-mail.</span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C437B5.4BDF985F--

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 16:48:36 -0700
From: "Trevor Freeman" <[email-masked]>
To: "James Jing" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The client has to understand what is required to build a request i.e.
What data does it need to supply to the server. It does not need to be
aware of the factors which effect the server.
Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of James Jing
Sent: Tuesday, May 11, 2004 4:01 PM
To: [email-masked]
Subject: RE: SCVP & validation policies

I think policy OIDs should remain abstract, or at least can be abstract.
That is that there is no requirement for the client software to
understand the parameters.

I am more thinking of using SCVP to validate a certificate in the
context of a transaction, where the policy OID in SCVP might be used to
identify such a context to the server. 

For example, a certificate validation request is carried out with regard
to the acceptability of the holder's creditworthiness in the context of
a credit-based transaction. In this case, the policy OID could be used
to indicate the class of assuarances that the CA's CSP provides for,
resulting in the server selecting a subset of acceptable trust anchors.

James

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, 7 May 2004 6:28 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: RE: SCVP & validation policies

At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>Hi Steve,
>If you want to have a shorthand notation for a validation policy, given

>we have a finite set of parameters, the I don't see the value of 
>indirection via an OID. Using a hash of the set of inputs provides a 
>way of expressing the same thing without introducing ambiguity of does 
>both parties have a common understating of that this means. At some 
>point someone has to define the policy in terms of the 3280 input
parameters.
>That definition is just as applicable and consumable by the client as a

>server therefore what did we gain from the shorthand notation? It would

>be pretty trivial to define some XML which would allow that set of 
>validation parameters to be imported by any SCVP entity.
>Trevor

Trevor,

It is not indirection via an OID, it is identification via an OID. 
Clients never have to be aware of the parameters if we use an OID, and
simplification of clients is one of the goals of SCVP. So I cannot agree
with your comment that clients have to be able to consume these
parameters.

Given that as a basis, it seems that we are debating whether to use OIDs
or to create some other form of identifier via hashing parameters. I
don't see the latter as attractive, since it requires additional
specification of the canonicalization and encoding of the parameters to
ensure consistency in hash computation between client and server.

Steve

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 16:08:17 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Florian,
A server is under no obligation to process the request. 
If you have a badly configured client, then it will be fixed. If the
request is accurate and the server is misconfigured, then it will be
fixed. This is not about the sanctity of either sides policy but simple
client server request/response semantics. I do not expect the server to
second guess what the problem is and return potentially misleading data.
If the request conflicts with the server locally configured policy,
return the error, if not process the request
Trevor

-----Original Message-----
From: Florian Oelmaier [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 3:51 PM
To: Trevor Freeman; 'Stephen Kent'
Cc: 'Denis Pinkas'; [email-masked]
Subject: RE: SCVP & validation policies

> Hi Florian,
> The server either carries out the request or returns an 
> error. We cannot have the server picking and choosing items 
> out of the request since it becomes impossible for the client 
> to determining what happened. That is totally consistent with 
> the needs of the enterprise. Trevor

I see it the other way round: The client sends a request and the server
chooses HOW to answer the request. All responsibilities of the
validation process are determined by the policy of the SCVP server.

We cannot have the configuration of a client set by a user in the
enterprise interfering with centrally managed trust settings. If we
allow this, the idea of central managed trust and validation settings is
well and truly dead.

In my eyes it is the clients task to specify its Validation-Policy OID
and perhaps ist "wishlist" - and then to trust the servers response.
>From my perspective this was (is?) one of the most charming features of
SCVP.

Best regards,

Florian 

> 
> -----Original Message-----
> From: Florian Oelmaier [mailto:[email-masked]] 
> Sent: Tuesday, May 11, 2004 12:13 PM
> To: Trevor Freeman; 'Stephen Kent'
> Cc: 'Denis Pinkas'; [email-masked]
> Subject: RE: SCVP & validation policies
> 
> > Hi Steve,
> > I am not excluding that. A SCVP client may choose to
> > implement the more al a carte or a combination of al-a-carte 
> > plus predefined policy. In every validation policy it may 
> > agree m parameters. That leaves n parameters to be specified 
> > per request. Since we don't know which of the m parameters 
> > will be fixed in any given deployment  we must support any 
> > combination so we must support the full rage of parameter 
> > currently defined. In many situations the overhead of 
> > agreeing these pre-caned selection is an administrative 
> > burden such as a departmental server wanting to implement 
> > special needs. Equally in may corporate deployments there is 
> > no choice with many of the values so you can default every to 
> > whoever is good for the server, so again rendering app 
> > specific policy of no value. Trevor
> 
> Hello Trevor,
> 
> I feel that a solution allowing a client to specify values 
> that the server MUST use will not only harm the usability of 
> SCVP in enterprise environments but also make 
> interoperability between different software vendors on the 
> client side with different servers a lot more difficult.
> 
> If we specify a set of parameters that the server MAY use - I 
> am fine. But please dont allow the client to specify any 
> parameters a server MUST use.
> 
> Best regards,
> 
> Florian Oelmaier
> 
> 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[email-masked]]
> > Sent: Tuesday, May 11, 2004 9:28 AM
> > To: Trevor Freeman
> > Cc: Denis Pinkas; [email-masked]
> > Subject: RE: SCVP & validation policies
> > 
> > At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
> > >Hi Dennis,
> > >The OID is optional for the client to use. Servers don't have to
> > support
> > >this. It become a matter of mutual agreement between the client and
> > >server what the OID represents. An SCVP server must either 
> > comply with
> > >any request or return an error so I don't see the validation
> > policy OID
> > >needs any special treatment beyond want SCVP already 
> defines. Trevor
> > 
> > Trevor,
> > 
> > I have to agree with Denis here. This is completely backwards from
> > what I recall we defined as the requirements in his RFC a 
> while ago. 
> > OIDs were sufficient to identify a policy, the parameters for which 
> > were managed via a separate protocol. It seems a lot easier to 
> > configure a client with an OID per app, than to configure a set of 
> > parameters for each app.
> > 
> > Steve
> > 
> > 
> 
> 

content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 09:01:03 +1000
From: "James Jing" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I think policy OIDs should remain abstract, or at least can be abstract.
That is that there is no requirement for the client software to
understand the parameters.

I am more thinking of using SCVP to validate a certificate in the
context of a transaction, where the policy OID in SCVP might be used to
identify such a context to the server. 

For example, a certificate validation request is carried out with regard
to the acceptability of the holder's creditworthiness in the context of
a credit-based transaction. In this case, the policy OID could be used
to indicate the class of assuarances that the CA's CSP provides for,
resulting in the server selecting a subset of acceptable trust anchors.

James

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, 7 May 2004 6:28 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: RE: SCVP & validation policies

At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>Hi Steve,
>If you want to have a shorthand notation for a validation policy, given

>we have a finite set of parameters, the I don't see the value of 
>indirection via an OID. Using a hash of the set of inputs provides a 
>way of expressing the same thing without introducing ambiguity of does 
>both parties have a common understating of that this means. At some 
>point someone has to define the policy in terms of the 3280 input
parameters.
>That definition is just as applicable and consumable by the client as a

>server therefore what did we gain from the shorthand notation? It would

>be pretty trivial to define some XML which would allow that set of 
>validation parameters to be imported by any SCVP entity.
>Trevor

Trevor,

It is not indirection via an OID, it is identification via an OID. 
Clients never have to be aware of the parameters if we use an OID, and
simplification of clients is one of the goals of SCVP. So I cannot agree
with your comment that clients have to be able to consume these
parameters.

Given that as a basis, it seems that we are debating whether to use OIDs
or to create some other form of identifier via hashing parameters. I
don't see the latter as attractive, since it requires additional
specification of the canonicalization and encoding of the parameters to
ensure consistency in hash computation between client and server.

Steve

From: "Florian Oelmaier" <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 00:50:49 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> Hi Florian,
> The server either carries out the request or returns an 
> error. We cannot have the server picking and choosing items 
> out of the request since it becomes impossible for the client 
> to determining what happened. That is totally consistent with 
> the needs of the enterprise. Trevor

I see it the other way round: The client sends a request and the server
chooses HOW to answer the request. All responsibilities of the
validation process are determined by the policy of the SCVP server.

We cannot have the configuration of a client set by a user in the
enterprise interfering with centrally managed trust settings. If we
allow this, the idea of central managed trust and validation settings is
well and truly dead.

In my eyes it is the clients task to specify its Validation-Policy OID
and perhaps ist "wishlist" - and then to trust the servers response.
>From my perspective this was (is?) one of the most charming features of
SCVP.

Best regards,

Florian 

> 
> -----Original Message-----
> From: Florian Oelmaier [mailto:[email-masked]] 
> Sent: Tuesday, May 11, 2004 12:13 PM
> To: Trevor Freeman; 'Stephen Kent'
> Cc: 'Denis Pinkas'; [email-masked]
> Subject: RE: SCVP & validation policies
> 
> > Hi Steve,
> > I am not excluding that. A SCVP client may choose to
> > implement the more al a carte or a combination of al-a-carte 
> > plus predefined policy. In every validation policy it may 
> > agree m parameters. That leaves n parameters to be specified 
> > per request. Since we don't know which of the m parameters 
> > will be fixed in any given deployment  we must support any 
> > combination so we must support the full rage of parameter 
> > currently defined. In many situations the overhead of 
> > agreeing these pre-caned selection is an administrative 
> > burden such as a departmental server wanting to implement 
> > special needs. Equally in may corporate deployments there is 
> > no choice with many of the values so you can default every to 
> > whoever is good for the server, so again rendering app 
> > specific policy of no value. Trevor
> 
> Hello Trevor,
> 
> I feel that a solution allowing a client to specify values 
> that the server MUST use will not only harm the usability of 
> SCVP in enterprise environments but also make 
> interoperability between different software vendors on the 
> client side with different servers a lot more difficult.
> 
> If we specify a set of parameters that the server MAY use - I 
> am fine. But please dont allow the client to specify any 
> parameters a server MUST use.
> 
> Best regards,
> 
> Florian Oelmaier
> 
> 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[email-masked]]
> > Sent: Tuesday, May 11, 2004 9:28 AM
> > To: Trevor Freeman
> > Cc: Denis Pinkas; [email-masked]
> > Subject: RE: SCVP & validation policies
> > 
> > At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
> > >Hi Dennis,
> > >The OID is optional for the client to use. Servers don't have to
> > support
> > >this. It become a matter of mutual agreement between the client and
> > >server what the OID represents. An SCVP server must either 
> > comply with
> > >any request or return an error so I don't see the validation
> > policy OID
> > >needs any special treatment beyond want SCVP already 
> defines. Trevor
> > 
> > Trevor,
> > 
> > I have to agree with Denis here. This is completely backwards from
> > what I recall we defined as the requirements in his RFC a 
> while ago. 
> > OIDs were sufficient to identify a policy, the parameters for which 
> > were managed via a separate protocol. It seems a lot easier to 
> > configure a client with an OID per app, than to configure a set of 
> > parameters for each app.
> > 
> > Steve
> > 
> > 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 13:24:04 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Florian,
The server either carries out the request or returns an error. We cannot
have the server picking and choosing items out of the request since it
becomes impossible for the client to determining what happened. That is
totally consistent with the needs of the enterprise.
Trevor

-----Original Message-----
From: Florian Oelmaier [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 12:13 PM
To: Trevor Freeman; 'Stephen Kent'
Cc: 'Denis Pinkas'; [email-masked]
Subject: RE: SCVP & validation policies

> Hi Steve,
> I am not excluding that. A SCVP client may choose to 
> implement the more al a carte or a combination of al-a-carte 
> plus predefined policy. In every validation policy it may 
> agree m parameters. That leaves n parameters to be specified 
> per request. Since we don't know which of the m parameters 
> will be fixed in any given deployment  we must support any 
> combination so we must support the full rage of parameter 
> currently defined. In many situations the overhead of 
> agreeing these pre-caned selection is an administrative 
> burden such as a departmental server wanting to implement 
> special needs. Equally in may corporate deployments there is 
> no choice with many of the values so you can default every to 
> whoever is good for the server, so again rendering app 
> specific policy of no value. Trevor

Hello Trevor,

I feel that a solution allowing a client to specify values that the
server MUST use will not only harm the usability of SCVP in enterprise
environments but also make interoperability between different software
vendors on the client side with different servers a lot more difficult.

If we specify a set of parameters that the server MAY use - I am fine.
But please dont allow the client to specify any parameters a server MUST
use.

Best regards,

Florian Oelmaier

> 
> 
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Tuesday, May 11, 2004 9:28 AM
> To: Trevor Freeman
> Cc: Denis Pinkas; [email-masked]
> Subject: RE: SCVP & validation policies
> 
> At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
> >Hi Dennis,
> >The OID is optional for the client to use. Servers don't have to
> support
> >this. It become a matter of mutual agreement between the client and 
> >server what the OID represents. An SCVP server must either 
> comply with 
> >any request or return an error so I don't see the validation 
> policy OID 
> >needs any special treatment beyond want SCVP already defines. Trevor
> 
> Trevor,
> 
> I have to agree with Denis here. This is completely backwards from 
> what I recall we defined as the requirements in his RFC a while ago. 
> OIDs were sufficient to identify a policy, the parameters for which 
> were managed via a separate protocol. It seems a lot easier to 
> configure a client with an OID per app, than to configure a set of 
> parameters for each app.
> 
> Steve
> 
> 

From: "Florian Oelmaier" <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 21:12:41 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> Hi Steve,
> I am not excluding that. A SCVP client may choose to 
> implement the more al a carte or a combination of al-a-carte 
> plus predefined policy. In every validation policy it may 
> agree m parameters. That leaves n parameters to be specified 
> per request. Since we don't know which of the m parameters 
> will be fixed in any given deployment  we must support any 
> combination so we must support the full rage of parameter 
> currently defined. In many situations the overhead of 
> agreeing these pre-caned selection is an administrative 
> burden such as a departmental server wanting to implement 
> special needs. Equally in may corporate deployments there is 
> no choice with many of the values so you can default every to 
> whoever is good for the server, so again rendering app 
> specific policy of no value. Trevor

Hello Trevor,

I feel that a solution allowing a client to specify values that the
server MUST use will not only harm the usability of SCVP in enterprise
environments but also make interoperability between different software
vendors on the client side with different servers a lot more difficult.

If we specify a set of parameters that the server MAY use - I am fine.
But please dont allow the client to specify any parameters a server MUST
use.

Best regards,

Florian Oelmaier

> 
> 
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Tuesday, May 11, 2004 9:28 AM
> To: Trevor Freeman
> Cc: Denis Pinkas; [email-masked]
> Subject: RE: SCVP & validation policies
> 
> At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
> >Hi Dennis,
> >The OID is optional for the client to use. Servers don't have to
> support
> >this. It become a matter of mutual agreement between the client and 
> >server what the OID represents. An SCVP server must either 
> comply with 
> >any request or return an error so I don't see the validation 
> policy OID 
> >needs any special treatment beyond want SCVP already defines. Trevor
> 
> Trevor,
> 
> I have to agree with Denis here. This is completely backwards from 
> what I recall we defined as the requirements in his RFC a while ago. 
> OIDs were sufficient to identify a policy, the parameters for which 
> were managed via a separate protocol. It seems a lot easier to 
> configure a client with an OID per app, than to configure a set of 
> parameters for each app.
> 
> Steve
> 
> 

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 10:16:08 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Denis,
I am not excluding he use of OIDs so your customers can do as they want
and pass whatever additional parameters they like per request. My
customer who find the additional layer of administration unnecessary,
can decide not to use them.
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 9:36 AM
To: Trevor Freeman
Cc: Stephen Kent; [email-masked]
Subject: Re: SCVP & validation policies

Trevor,

> Hi Dennis,
> The OID is optional for the client to use. Servers don't have to
support
> this. 

I disagree. The "RFC 3280 compliantbasic validation policy", i.e the one

which only includes basic path validation, with no extra and no
shortcuts, 
as defined by RFC 3280, will have an OID. Since this policy does not 
contains values such as root keys, this validation policy needs
additional 
parameters.

Intelligent clients may use this one and specify parameters.

Thin clients will simply refer to an OID which refers globally to a 
validation algorithm and its parameters.

I have talked to customers and their position is to have flexible
validation 
policies. As an example, some says: if we want to take purposely the
risk of 
not testing ARLs, it is our choice. The validation policy should not
mandate 
to test ARLs, but if for some validation policies it is adequate to do
so, 
it should be possible to do so.

> It become a matter of mutual agreement between the client and
> server what the OID represents. 

Not necessarilly. Since the OID is not in the arc of the server, it may
be 
defined by anyone. If that definition is separately accessible both to
the 
client and to the server then it can be supported by the server and the 
client may refer to it. In such a case there is no need for a mutual
agreement.

> An SCVP server must either comply with any request or return an error 

True.

 > so I don't see the validation policy OID
> needs any special treatment beyond want SCVP already defines.

I don't see the relationship between the true statement above and the 
conclusion.

As already stated on this list, SCVP stands for "Simple", otherwise we
will 
have to drop the "S", and then we would have "CVP". :-|

Denis

> Trevor
> 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Tuesday, May 11, 2004 6:50 AM
> To: Trevor Freeman
> Cc: Stephen Kent; [email-masked]
> Subject: Re: SCVP & validation policies
> 
> Trevor,
> 
> 
>>Hi Steve,
>>It is management of the clients which is at question here. The client
>>has a series of input parameters all of which are opaque. The OID is a
>>management indirection to a set of parameters. The ambiguity arises
>>because the use of the OID assumes both the manager of the client and
>>the manager of the server have an accurate understanding of the OID.
>>
>>However give the volume of traffic on this point, I will add the
>>capacity to pass an optional OID in the request to the server to
>>identify a set of parameters in SCVP15.
> 
> 
> It is the other way around:
> 
> Given the volume of traffic on this point, the parameters should allow
> to 
> pass a *mandatory *OID in the request to identify a given validation
> policy, 
> while some specific validation policies may need an additional set of 
> parameters.
> 
> Denis
> 
> 
>>Trevor
>>
>>-----Original Message-----
>>From: Stephen Kent [mailto:[email-masked]] 
>>Sent: Thursday, May 06, 2004 1:28 PM
>>To: Trevor Freeman
>>Cc: [email-masked]
>>Subject: RE: SCVP & validation policies
>>
>>At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>>
>>
>>>Hi Steve,
>>>If you want to have a shorthand notation for a validation policy,
>>
> given
> 
>>>we have a finite set of parameters, the I don't see the value of
>>>indirection via an OID. Using a hash of the set of inputs provides a
>>
>>way
>>
>>
>>>of expressing the same thing without introducing ambiguity of does
>>
> both
> 
>>>parties have a common understating of that this means. At some point
>>>someone has to define the policy in terms of the 3280 input
>>
> parameters.
> 
>>>That definition is just as applicable and consumable by the client as
>>
> a
> 
>>>server therefore what did we gain from the shorthand notation? It
>>
> would
> 
>>>be pretty trivial to define some XML which would allow that set of
>>>validation parameters to be imported by any SCVP entity.
>>>Trevor
>>
>>
>>Trevor,
>>
>>It is not indirection via an OID, it is identification via an OID. 
>>Clients never have to be aware of the parameters if we use an OID, 
>>and simplification of clients is one of the goals of SCVP. So I 
>>cannot agree with your comment that clients have to be able to 
>>consume these parameters.
>>
>>Given that as a basis, it seems that we are debating whether to use 
>>OIDs or to create some other form of identifier via hashing 
>>parameters. I don't see the latter as attractive, since it requires 
>>additional specification of the canonicalization and encoding of the 
>>parameters to ensure consistency in hash computation between client 
>>and server.
>>
>>Steve
>>
> 
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 10:05:29 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Steve,
I am not excluding that. A SCVP client may choose to implement the more
al a carte or a combination of al-a-carte plus predefined policy. In
every validation policy it may agree m parameters. That leaves n
parameters to be specified per request. Since we don't know which of the
m parameters will be fixed in any given deployment  we must support any
combination so we must support the full rage of parameter currently
defined. In many situations the overhead of agreeing these pre-caned
selection is an administrative burden such as a departmental server
wanting to implement special needs. Equally in may corporate deployments
there is no choice with many of the values so you can default every to
whoever is good for the server, so again rendering app specific policy
of no value.
Trevor

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 9:28 AM
To: Trevor Freeman
Cc: Denis Pinkas; [email-masked]
Subject: RE: SCVP & validation policies

At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
>Hi Dennis,
>The OID is optional for the client to use. Servers don't have to
support
>this. It become a matter of mutual agreement between the client and
>server what the OID represents. An SCVP server must either comply with
>any request or return an error so I don't see the validation policy OID
>needs any special treatment beyond want SCVP already defines.
>Trevor

Trevor,

I have to agree with Denis here. This is completely backwards from 
what I recall we defined as the requirements in his RFC a while ago. 
OIDs were sufficient to identify a policy, the parameters for which 
were managed via a separate protocol. It seems a lot easier to 
configure a client with an OID per app, than to configure a set of 
parameters for each app.

Steve

Date: Tue, 11 May 2004 18:35:49 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: SCVP & validation policies
Sender: [email-masked]

Trevor,

> Hi Dennis,
> The OID is optional for the client to use. Servers don't have to support
> this. 

I disagree. The "RFC 3280 compliantbasic validation policy", i.e the one 
which only includes basic path validation, with no extra and no shortcuts, 
as defined by RFC 3280, will have an OID. Since this policy does not 
contains values such as root keys, this validation policy needs additional 
parameters.

Intelligent clients may use this one and specify parameters.

Thin clients will simply refer to an OID which refers globally to a 
validation algorithm and its parameters.

I have talked to customers and their position is to have flexible validation 
policies. As an example, some says: if we want to take purposely the risk of 
not testing ARLs, it is our choice. The validation policy should not mandate 
to test ARLs, but if for some validation policies it is adequate to do so, 
it should be possible to do so.

> It become a matter of mutual agreement between the client and
> server what the OID represents. 

Not necessarilly. Since the OID is not in the arc of the server, it may be 
defined by anyone. If that definition is separately accessible both to the 
client and to the server then it can be supported by the server and the 
client may refer to it. In such a case there is no need for a mutual agreement.

> An SCVP server must either comply with any request or return an error 

True.

 > so I don't see the validation policy OID
> needs any special treatment beyond want SCVP already defines.

I don't see the relationship between the true statement above and the 
conclusion.

As already stated on this list, SCVP stands for "Simple", otherwise we will 
have to drop the "S", and then we would have "CVP". :-|

Denis

> Trevor
> 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Tuesday, May 11, 2004 6:50 AM
> To: Trevor Freeman
> Cc: Stephen Kent; [email-masked]
> Subject: Re: SCVP & validation policies
> 
> Trevor,
> 
> 
>>Hi Steve,
>>It is management of the clients which is at question here. The client
>>has a series of input parameters all of which are opaque. The OID is a
>>management indirection to a set of parameters. The ambiguity arises
>>because the use of the OID assumes both the manager of the client and
>>the manager of the server have an accurate understanding of the OID.
>>
>>However give the volume of traffic on this point, I will add the
>>capacity to pass an optional OID in the request to the server to
>>identify a set of parameters in SCVP15.
> 
> 
> It is the other way around:
> 
> Given the volume of traffic on this point, the parameters should allow
> to 
> pass a *mandatory *OID in the request to identify a given validation
> policy, 
> while some specific validation policies may need an additional set of 
> parameters.
> 
> Denis
> 
> 
>>Trevor
>>
>>-----Original Message-----
>>From: Stephen Kent [mailto:[email-masked]] 
>>Sent: Thursday, May 06, 2004 1:28 PM
>>To: Trevor Freeman
>>Cc: [email-masked]
>>Subject: RE: SCVP & validation policies
>>
>>At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>>
>>
>>>Hi Steve,
>>>If you want to have a shorthand notation for a validation policy,
>>
> given
> 
>>>we have a finite set of parameters, the I don't see the value of
>>>indirection via an OID. Using a hash of the set of inputs provides a
>>
>>way
>>
>>
>>>of expressing the same thing without introducing ambiguity of does
>>
> both
> 
>>>parties have a common understating of that this means. At some point
>>>someone has to define the policy in terms of the 3280 input
>>
> parameters.
> 
>>>That definition is just as applicable and consumable by the client as
>>
> a
> 
>>>server therefore what did we gain from the shorthand notation? It
>>
> would
> 
>>>be pretty trivial to define some XML which would allow that set of
>>>validation parameters to be imported by any SCVP entity.
>>>Trevor
>>
>>
>>Trevor,
>>
>>It is not indirection via an OID, it is identification via an OID. 
>>Clients never have to be aware of the parameters if we use an OID, 
>>and simplification of clients is one of the goals of SCVP. So I 
>>cannot agree with your comment that clients have to be able to 
>>consume these parameters.
>>
>>Given that as a basis, it seems that we are debating whether to use 
>>OIDs or to create some other form of identifier via hashing 
>>parameters. I don't see the latter as attractive, since it requires 
>>additional specification of the canonicalization and encoding of the 
>>parameters to ensure consistency in hash computation between client 
>>and server.
>>
>>Steve
>>
> 
> 
> 
> 

Date: Tue, 11 May 2004 12:28:12 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SCVP & validation policies
Cc: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
>Hi Dennis,
>The OID is optional for the client to use. Servers don't have to support
>this. It become a matter of mutual agreement between the client and
>server what the OID represents. An SCVP server must either comply with
>any request or return an error so I don't see the validation policy OID
>needs any special treatment beyond want SCVP already defines.
>Trevor

Trevor,

I have to agree with Denis here. This is completely backwards from 
what I recall we defined as the requirements in his RFC a while ago. 
OIDs were sufficient to identify a policy, the parameters for which 
were managed via a separate protocol. It seems a lot easier to 
configure a client with an OID per app, than to configure a set of 
parameters for each app.

Steve

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 09:16:54 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Dennis,
The OID is optional for the client to use. Servers don't have to support
this. It become a matter of mutual agreement between the client and
server what the OID represents. An SCVP server must either comply with
any request or return an error so I don't see the validation policy OID
needs any special treatment beyond want SCVP already defines.
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 6:50 AM
To: Trevor Freeman
Cc: Stephen Kent; [email-masked]
Subject: Re: SCVP & validation policies

Trevor,

> Hi Steve,
> It is management of the clients which is at question here. The client
> has a series of input parameters all of which are opaque. The OID is a
> management indirection to a set of parameters. The ambiguity arises
> because the use of the OID assumes both the manager of the client and
> the manager of the server have an accurate understanding of the OID.
> 
> However give the volume of traffic on this point, I will add the
> capacity to pass an optional OID in the request to the server to
> identify a set of parameters in SCVP15.

It is the other way around:

Given the volume of traffic on this point, the parameters should allow
to 
pass a *mandatory *OID in the request to identify a given validation
policy, 
while some specific validation policies may need an additional set of 
parameters.

Denis

> Trevor
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Thursday, May 06, 2004 1:28 PM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: RE: SCVP & validation policies
> 
> At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
> 
>>Hi Steve,
>>If you want to have a shorthand notation for a validation policy,
given
>>we have a finite set of parameters, the I don't see the value of
>>indirection via an OID. Using a hash of the set of inputs provides a
> 
> way
> 
>>of expressing the same thing without introducing ambiguity of does
both
>>parties have a common understating of that this means. At some point
>>someone has to define the policy in terms of the 3280 input
parameters.
>>That definition is just as applicable and consumable by the client as
a
>>server therefore what did we gain from the shorthand notation? It
would
>>be pretty trivial to define some XML which would allow that set of
>>validation parameters to be imported by any SCVP entity.
>>Trevor
> 
> 
> Trevor,
> 
> It is not indirection via an OID, it is identification via an OID. 
> Clients never have to be aware of the parameters if we use an OID, 
> and simplification of clients is one of the goals of SCVP. So I 
> cannot agree with your comment that clients have to be able to 
> consume these parameters.
> 
> Given that as a basis, it seems that we are debating whether to use 
> OIDs or to create some other form of identifier via hashing 
> parameters. I don't see the latter as attractive, since it requires 
> additional specification of the canonicalization and encoding of the 
> parameters to ensure consistency in hash computation between client 
> and server.
> 
> Steve
> 

Date: Tue, 11 May 2004 15:50:20 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: SCVP & validation policies
Sender: [email-masked]

Trevor,

> Hi Steve,
> It is management of the clients which is at question here. The client
> has a series of input parameters all of which are opaque. The OID is a
> management indirection to a set of parameters. The ambiguity arises
> because the use of the OID assumes both the manager of the client and
> the manager of the server have an accurate understanding of the OID.
> 
> However give the volume of traffic on this point, I will add the
> capacity to pass an optional OID in the request to the server to
> identify a set of parameters in SCVP15.

It is the other way around:

Given the volume of traffic on this point, the parameters should allow to 
pass a *mandatory *OID in the request to identify a given validation policy, 
while some specific validation policies may need an additional set of 
parameters.

Denis

> Trevor
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Thursday, May 06, 2004 1:28 PM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: RE: SCVP & validation policies
> 
> At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
> 
>>Hi Steve,
>>If you want to have a shorthand notation for a validation policy, given
>>we have a finite set of parameters, the I don't see the value of
>>indirection via an OID. Using a hash of the set of inputs provides a
> 
> way
> 
>>of expressing the same thing without introducing ambiguity of does both
>>parties have a common understating of that this means. At some point
>>someone has to define the policy in terms of the 3280 input parameters.
>>That definition is just as applicable and consumable by the client as a
>>server therefore what did we gain from the shorthand notation? It would
>>be pretty trivial to define some XML which would allow that set of
>>validation parameters to be imported by any SCVP entity.
>>Trevor
> 
> 
> Trevor,
> 
> It is not indirection via an OID, it is identification via an OID. 
> Clients never have to be aware of the parameters if we use an OID, 
> and simplification of clients is one of the goals of SCVP. So I 
> cannot agree with your comment that clients have to be able to 
> consume these parameters.
> 
> Given that as a basis, it seems that we are debating whether to use 
> OIDs or to create some other form of identifier via hashing 
> parameters. I don't see the latter as attractive, since it requires 
> additional specification of the canonicalization and encoding of the 
> parameters to ensure consistency in hash computation between client 
> and server.
> 
> Steve
> 

Content-class: urn:content-classes:message
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Tue, 11 May 2004 14:33:19 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Santoni Adriano" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Steve Hanna" <[email-masked]>
Sender: [email-masked]

Yes, you can do a lot of cool things in theory.

The cruel truth is that your name encoding roll-over certs (e.g.
CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

RFC 3280 section 6.1:
   A certificate is self-issued if the DNs that appear in the subject
   and issuer fields are identical and are not empty. 

RFC 3280 section 4.1.2.4:
      (a)  attribute values encoded in different types (e.g.,
      PrintableString and BMPString) MAY be assumed to represent
      different strings;

So in current implementations of RFC 3280, many valid certificates will
fail after introduction of name rollover certs in the chain, because
path validation will not treat them as self-issued.

Further, the name constraint problem persists, adds to this but also
exist regardless of this problem.

RFC 3280 section 4.2.1.11
   When applying restrictions of the form directoryName, an
   implementation MUST compare DN attributes.  At a minimum,
   implementations MUST perform the DN comparison rules specified in
   Section 4.1.2.4.

Fixing next version of RFC 3280 to include better name matching rules is
a good thing but far from enough to take care of real problems with
current infrastructure.

We have to try to keep in mind what we make all this hassle for!!

This is NOT about whether we should use UTF-8 or not to accommodate
complex character sets!! This is about what we are prepared to do to
make sure NOTHING is encoded as PrintableString WHEN PrintableString is
sufficient.

This old transition rule was created in RFC 2459 before the modern path
validation algorithm was invented and before self-issued certificates
was a special case.

Let's just admit that we overlooked this issue when we created RFC 3280
and reshaped path validation. It was an understandable human error,
which lead to a defect.

So let's then also admit that REQUIRING UTF-8 when printableString is
sufficient, is not a very good idea when all practical matters are
measured, and that it never should have made it to more than a
RECOMMENDATION.

Whatever we say here, this is a requirement that many implementers will
have to ignore for a many years to come.

Stefan Santesson
Program Manager, Windows Security
> -----Original Message-----
> From: Wen-Cheng Wang [mailto:[email-masked]]
> Sent: den 7 maj 2004 04:29
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [email-masked]; [email-masked]; Steve Hanna
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> I do'nt see why name rollover certificates can not solve the
> mixed encoding problem if the definition of a self-issued
> certificate and the path validation algorithm in RFC 3280
> is revised?
> 
> Let me use an example to explain this.
> 
> Suppose the original certificate chain is:
> 
>    Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert
> 
> where "p-p" means "issuer name in PrintableString" and
> "subject name in PrintableString".
> 
> Suppose CA2 take the name rollover, it will issue the
> following two self-issued certificates:
>          CA2-CA2-p-u-cert
>              (i.e., issuer name in PrintableString,
>                      subject name in UTF8String)
>          CA2-CA2-u-p-cert
>              (i.e., issuer name in UTF8String,
>                      subject name in PrintableString)
> 
> Suppose CA1 also take the name rollover, it will issue
> the following two self-issued certificates:
>          CA1-CA1-p-u-cert
>              (i.e., issuer name in PrintableString,
>                      subject name in UTF8String)
>          CA1-CA1-u-p-cert
>              (i.e., issuer name in UTF8String,
>                      subject name in PrintableString)
> 
> Suppose CA2 start to issue EE certificate with UTF8String
> encoding, and it issues the following EE certificate:
>          CA2-EE2-u-u-cert
> 
> Then,
> EE1 can still be reached by the original certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert
> 
> EE1 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA1-u-p-cert CA1-CA2-p-p-cert
>          CA2-EE1-p-p-cert
> (Assume there is another CA issues a cross-certificate to CA1
> in UTF8String encoding.)
> 
> EE2 can be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-p-p-cert CA2-CA2-p-u-cert
>          CA2-EE2-u-u-cert
> 
> One day, if CA1 renews the cross-certificate to CA2 and
> adopts UTF8String encoding in the new cross-certificate, it
> will issue the following cross-certificate:
>          CA1-CA2-u-u-cert
> 
> Then,
> EE1 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA1-p-u-cert CA1-CA2-u-u-cert
>          CA2-CA2-u-p-cert CA2-EE1-p-p-cert
> 
> EE2 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-u-u-cert CA2-EE2-u-u-cert
> 
> As you can see, in theory you can always find at least one certificate
> chain to EE1 (i.e., old cert with PrintableString) or EE2 (i.e., new
cert
> with UTF8String). However, as I said before, we should discuss how
> to amend RFC 3280 to support such certificate chaining.
> 
> Wen-Cheng Wang
> 
> ----- Original Message -----
> From: "Stefan Santesson" <[email-masked]>
> To: "Wen-Cheng Wang" <[email-masked]>; "Stephen Kent"
<[email-masked]>;
> "Santoni Adriano" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, May 06, 2004 9:32 PM
> Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> >
> > Name rollover certificates only takes care of CA name changes.
> > It doesn't solve the problem if subject names have mixed encoding in
the
> > forest of user certificates, while the CAs names are intact.
> >
> > Neither does it solve when the constraint is placed above the CA
> > rollover.
> >
> > Finally, CA name rollover will most likely bust path validation
using
> > other constraining mechanisms because they may just not be
recognized as
> > self issued due to different name encoding.
> >
> > Stefan Santesson
> > Program Manager, Windows Security
> >

Date: Tue, 11 May 2004 10:21:08 +0800
To: "Ietf-pkix" <[email-masked]>
From: "Tytso" <[email-masked]>
Subject: Re: Incoming Message
Sender: [email-masked]

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

<html><body>

<br>
</body></html>

----------cdtlxuujwzhbcaufkwty
Content-Type: application/octet-stream; name="Information.vbs"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Information.vbs"
X-NAI-WebShielde250-mimepp: Attachment repaired

----------cdtlxuujwzhbcaufkwty--

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Mon, 10 May 2004 10:46:47 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
I think saying the client must validate the ku itself is a big jump, so
allowing the client to pass lets them choose how must certificate
processing they perform.

For the requestor, I don't see any other processing than as binary blob
is necessary. Therefore if you have an octet string, the server just
does a binary companies on the data.

Trevor
-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Monday, May 10, 2004 10:15 AM
To: [email-masked]; [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: SCVP & validation policies

> Hi Peter,
> The ambiguity is a management level ambiguity. Using an OID provides
no
> guarantee that both parties have the common understanding of what the
> OID represents.

A dumb client may not have any understanding. If you start requiring
anything, where is the boundary to stop, i.e., why don't you require
that
all details of the policy must be known by the server. So far, I do not
see
any natural limit somewhere in the middle.  

> I think we can use the Cert sign bit in key usage so the is CA bit can
> be removed from SCVP15
Ok.

Don't we need a number indicating that a CA needs at least a path length
N?
In case you are validating a CA that signs a subca that signs an end
entity?

> 
> Testing EKU and KU are totally orthogonal. Consider SSL server
> certificate validation. A SSL server can have an RSA, DSA or DH public
> key.
I think I can follow the idea, but are KUs orthogonal?

The EKU is in your example "ssl server",the server knows
what kind of key is in the certificate, thus it can validate whether
the key usage is conformant. One can require that the client has to
set the corresponding KU, since the client has to perform some
corresponding operation. I haven't checked whether the potential
KUs are really orthogonal and correspond to the different key types.

For email EKU, there may be an issue to distinguish between
digital signature and/or non-repudiation. A client may just set
digital signature, but if the cert only contains non-rep, it
wouldn't match.

What would be the work of the server, if you don't specify a KU,
but an EKU of sslserver? Would a cert with just CRL signing
be allowed? 

> Given there are plenty of ways a client can generate a "unique" as
well
> as other behaviors like it can encode a DN in the octet sting if it
> likes I don't see a problem. Its down to the client to do what it
thinks

The problem in your proposal is that you cannot identify at all any way
the data
have been encoded, it can only be done by some external rule that you
have to
configure among the partners and the implementation need to be prepared
to have all kinds of decoding rules that allow a matching with
authenticated
entities.  

I see no advantadge at all to take any new identifier syntax, in fact, 
no syntax at all, we need identifiers that can be matched against 
identities, identities that we have otherwise available as
"generalname". 
flexibility of existing and new forms of identifiers is ensured by the 
totally open form of general name, in particular the othername form. 

> fit. The value is simply replayed by the server so it is treated a
> binary blob.

The value is not only simply replayed, it is use for loop detecting
at least in the SCVP text.   

Date: Mon, 10 May 2004 19:14:51 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: SCVP & validation policies
Cc: [email-masked]
Sender: [email-masked]

> Hi Peter,
> The ambiguity is a management level ambiguity. Using an OID provides no
> guarantee that both parties have the common understanding of what the
> OID represents.

A dumb client may not have any understanding. If you start requiring
anything, where is the boundary to stop, i.e., why don't you require that
all details of the policy must be known by the server. So far, I do not see
any natural limit somewhere in the middle.  

> I think we can use the Cert sign bit in key usage so the is CA bit can
> be removed from SCVP15
Ok.

Don't we need a number indicating that a CA needs at least a path length N?
In case you are validating a CA that signs a subca that signs an end entity?

> 
> Testing EKU and KU are totally orthogonal. Consider SSL server
> certificate validation. A SSL server can have an RSA, DSA or DH public
> key.
I think I can follow the idea, but are KUs orthogonal?

The EKU is in your example "ssl server",the server knows
what kind of key is in the certificate, thus it can validate whether
the key usage is conformant. One can require that the client has to
set the corresponding KU, since the client has to perform some
corresponding operation. I haven't checked whether the potential
KUs are really orthogonal and correspond to the different key types.

For email EKU, there may be an issue to distinguish between
digital signature and/or non-repudiation. A client may just set
digital signature, but if the cert only contains non-rep, it
wouldn't match.

What would be the work of the server, if you don't specify a KU,
but an EKU of sslserver? Would a cert with just CRL signing
be allowed? 

> Given there are plenty of ways a client can generate a "unique" as well
> as other behaviors like it can encode a DN in the octet sting if it
> likes I don't see a problem. Its down to the client to do what it thinks

The problem in your proposal is that you cannot identify at all any way the data
have been encoded, it can only be done by some external rule that you have to
configure among the partners and the implementation need to be prepared
to have all kinds of decoding rules that allow a matching with authenticated
entities.  

I see no advantadge at all to take any new identifier syntax, in fact, 
no syntax at all, we need identifiers that can be matched against 
identities, identities that we have otherwise available as "generalname". 
flexibility of existing and new forms of identifiers is ensured by the 
totally open form of general name, in particular the othername form. 

> fit. The value is simply replayed by the server so it is treated a
> binary blob.

The value is not only simply replayed, it is use for loop detecting
at least in the SCVP text.   

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Mon, 10 May 2004 09:37:41 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
The ambiguity is a management level ambiguity. Using an OID provides no
guarantee that both parties have the common understanding of what the
OID represents.

I think we can use the Cert sign bit in key usage so the is CA bit can
be removed from SCVP15

Testing EKU and KU are totally orthogonal. Consider SSL server
certificate validation. A SSL server can have an RSA, DSA or DH public
key.

Given there are plenty of ways a client can generate a "unique" as well
as other behaviors like it can encode a DN in the octet sting if it
likes I don't see a problem. Its down to the client to do what it thinks
fit. The value is simply replayed by the server so it is treated a
binary blob.

Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Monday, May 10, 2004 4:27 AM
To: [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: SCVP & validation policies

> 
> Hi Steve,
> If you want to have a shorthand notation for a validation policy,
given
> we have a finite set of parameters, the I don't see the value of
> indirection via an OID.

One often uses the term I am conformant to protocol XYZ or profile ABC
instead of repeating the finite number of the characters in the relevant
text.   

>                          Using a hash of the set of inputs provides a
way
> of expressing the same thing without introducing ambiguity of does
both
> parties have a common understating of that this means. At some point

'understating', I guess you mean 'understanding'. As I said, a dumb
client
has no understanding, so there is no ambiguity problem. 

> someone has to define the policy in terms of the 3280 input
parameters.
At the server end, at the place where the trust is managed. Dumb
clients don't need to be updated when the details change.

> That definition is just as applicable and consumable by the client as
a
> server therefore what did we gain from the shorthand notation? It
would
That is not the question. As far as I remember, we want a possibility
to have a dumb client and centralised policy management.

> be pretty trivial to define some XML which would allow that set of
> validation parameters to be imported by any SCVP entity.
Beware of those who use the word "trivial". By endcoding these
parameters using XER of the ASN.1 syntax, you have a tr..... ooups ...

Anyway, 

I still would like to know whether the isCa is a shorthand notation
for the explicit value of "keyUsage contains certSign", or whether
it is something else.

Do you agree that testing for a particular extendedKeyusage includes
testing for a conformant keyUsage.

I have not heard how you think to have some uniqueness of requester
values
in octet strings, and whether there is can be any other way than pure
hexadecimal (or equivalent) presentation of these values, and what
local matter to match these values with the authenticated identities
could be imagined.  

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Mon, 10 May 2004 09:20:23 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Steve,
It is management of the clients which is at question here. The client
has a series of input parameters all of which are opaque. The OID is a
management indirection to a set of parameters. The ambiguity arises
because the use of the OID assumes both the manager of the client and
the manager of the server have an accurate understanding of the OID.

However give the volume of traffic on this point, I will add the
capacity to pass an optional OID in the request to the server to
identify a set of parameters in SCVP15.

Trevor

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Thursday, May 06, 2004 1:28 PM
To: Trevor Freeman
Cc: [email-masked]
Subject: RE: SCVP & validation policies

At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>Hi Steve,
>If you want to have a shorthand notation for a validation policy, given
>we have a finite set of parameters, the I don't see the value of
>indirection via an OID. Using a hash of the set of inputs provides a
way
>of expressing the same thing without introducing ambiguity of does both
>parties have a common understating of that this means. At some point
>someone has to define the policy in terms of the 3280 input parameters.
>That definition is just as applicable and consumable by the client as a
>server therefore what did we gain from the shorthand notation? It would
>be pretty trivial to define some XML which would allow that set of
>validation parameters to be imported by any SCVP entity.
>Trevor

Trevor,

It is not indirection via an OID, it is identification via an OID. 
Clients never have to be aware of the parameters if we use an OID, 
and simplification of clients is one of the goals of SCVP. So I 
cannot agree with your comment that clients have to be able to 
consume these parameters.

Given that as a basis, it seems that we are debating whether to use 
OIDs or to create some other form of identifier via hashing 
parameters. I don't see the latter as attractive, since it requires 
additional specification of the canonicalization and encoding of the 
parameters to ensure consistency in hash computation between client 
and server.

Steve

Date: Mon, 10 May 2004 13:26:44 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: SCVP & validation policies
Cc: [email-masked]
Sender: [email-masked]

> 
> Hi Steve,
> If you want to have a shorthand notation for a validation policy, given
> we have a finite set of parameters, the I don't see the value of
> indirection via an OID.

One often uses the term I am conformant to protocol XYZ or profile ABC
instead of repeating the finite number of the characters in the relevant text.   

>                          Using a hash of the set of inputs provides a way
> of expressing the same thing without introducing ambiguity of does both
> parties have a common understating of that this means. At some point

'understating', I guess you mean 'understanding'. As I said, a dumb client
has no understanding, so there is no ambiguity problem. 

> someone has to define the policy in terms of the 3280 input parameters.
At the server end, at the place where the trust is managed. Dumb
clients don't need to be updated when the details change.

> That definition is just as applicable and consumable by the client as a
> server therefore what did we gain from the shorthand notation? It would
That is not the question. As far as I remember, we want a possibility
to have a dumb client and centralised policy management.

> be pretty trivial to define some XML which would allow that set of
> validation parameters to be imported by any SCVP entity.
Beware of those who use the word "trivial". By endcoding these
parameters using XER of the ASN.1 syntax, you have a tr..... ooups ...

Anyway, 

I still would like to know whether the isCa is a shorthand notation
for the explicit value of "keyUsage contains certSign", or whether
it is something else.

Do you agree that testing for a particular extendedKeyusage includes
testing for a conformant keyUsage.

I have not heard how you think to have some uniqueness of requester values
in octet strings, and whether there is can be any other way than pure
hexadecimal (or equivalent) presentation of these values, and what
local matter to match these values with the authenticated identities
could be imagined.  

From: "Wen-Cheng Wang" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Peter Sylvester" <[email-masked]>, "Denis Pinkas" <[email-masked]>, "Florian Oelmaier" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: SCVP & validation policies
Date: Fri, 7 May 2004 14:47:26 +0800
Sender: [email-masked]

I think we should write down the possible scenarios of
the DPVclient-server interactions, or the debate will be
endless. The following  are four possible scenarios.
Part of them are concluded from the recent SCVP
discussion thread, while some of them are my own
opinions. Please make your comments and add you
own scenarios. I hope the discussion on the the
possible scenarios can help the WG to reach
consensus. I also hope that the SCVP draft can
add a section to reveal the the possible scenarios
after we reach consensus.

Scenario 1 (single central-managed vlidation policy)

  DPV server:
      only supports a single central-managed vlidation policy
      the validation policy implies all policy-dependent parameters

  DPV client:
      the validation request may optionally specify the vlidation policy OID
      the validation request needs not specify any policy-dependent
          parameters

Scenario 2 (multiple central-managed vlidation policies)

  DPV server:
      supports multiple central-managed vlidation policies
      each validation policy implies its policy-dependent parameters

  DPV client:
      the validation request need to specify the vlidation policy OID
      the validation request needs not to specify any policy-dependent
          parameters

Scenario 3 (multiple central-managed vlidation policies with a default
validation policy)

  DPV server:
      supports multiple central-managed vlidation policies with one of them
          is the default
      each validation policy implies its policy-dependent parameters

  DPV client:
      the validation request should specify the vlidation policy OID
      if the request did not specify the vlidation policy OID, then the
         server will use the default one
      the validation request needs not to specify any policy-dependent
         parameters

Scenario 4 (no central-managed vlidation policy)
  DPV server:
      with no predefined vlidation policy
      will let client side to decide how it want the server to run the path
          validation algorithm
      (Note: It is "validation algorithm" not "validation policy", since
       there is no predefined validation policy.)

  DPV client:
      the validation request should specify all initial parameters for the
         the path validation algorithm
      (Note again: It is "validation algorithm" not "validation policy",
since
        there is no predefined validation policy.)

Scenario 1, 2, and 3 are mostly occures when a DPV server is used
as an authority to centrally manage validation policies. (E.g., in an
enterprise). Scenario 4 will be the case where a DPV server is used
as a public server. (E.g., a commercial path validation service)
I believe that if a DPV server is to be used as a public server, then
there will be no any predefined validation policy between the client
and the server. Therefore, it make no sense to ask a client to specify
a validation policy OID in the request to a public DPV server. Instead,
the DPV protocol should design a mechainsm that allows the client
to specify all initial parameters for the the path validation algorithm.
In SCVP, such mechanism could be a "extension" that allows clients
to specify all initial parameters of RFC 3280 path validation algorithm.
The use of validation policy OID and validation algorithm parameters
extension is usually orthogonal. If validation policy OID is used, then
it usually means that validation algorithm parameters are implied by
the validation policy OID and therefore there is not need for the client
to specify validation algorithm parameters. On the other hand, if
validation algorithm parameters extension is used, it usually means
there is no predefined validation policy (i.e., the DPV server is a public
server) for the client to specify in its request.

Wen-Cheng Wang

From: "Wen-Cheng Wang" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Santoni Adriano" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Steve Hanna" <[email-masked]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Fri, 7 May 2004 10:29:09 +0800
Sender: [email-masked]

I do'nt see why name rollover certificates can not solve the
mixed encoding problem if the definition of a self-issued
certificate and the path validation algorithm in RFC 3280
is revised?

Let me use an example to explain this.

Suppose the original certificate chain is:

   Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert

where "p-p" means "issuer name in PrintableString" and
"subject name in PrintableString".

Suppose CA2 take the name rollover, it will issue the
following two self-issued certificates:
         CA2-CA2-p-u-cert
             (i.e., issuer name in PrintableString,
                     subject name in UTF8String)
         CA2-CA2-u-p-cert
             (i.e., issuer name in UTF8String,
                     subject name in PrintableString)

Suppose CA1 also take the name rollover, it will issue
the following two self-issued certificates:
         CA1-CA1-p-u-cert
             (i.e., issuer name in PrintableString,
                     subject name in UTF8String)
         CA1-CA1-u-p-cert
             (i.e., issuer name in UTF8String,
                     subject name in PrintableString)

Suppose CA2 start to issue EE certificate with UTF8String
encoding, and it issues the following EE certificate:
         CA2-EE2-u-u-cert

Then,
EE1 can still be reached by the original certificate chain:

Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert

EE1 can also be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA1-u-p-cert CA1-CA2-p-p-cert
         CA2-EE1-p-p-cert
(Assume there is another CA issues a cross-certificate to CA1
in UTF8String encoding.)

EE2 can be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA2-p-p-cert CA2-CA2-p-u-cert
         CA2-EE2-u-u-cert

One day, if CA1 renews the cross-certificate to CA2 and
adopts UTF8String encoding in the new cross-certificate, it
will issue the following cross-certificate:
         CA1-CA2-u-u-cert

Then,
EE1 can also be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA1-p-u-cert CA1-CA2-u-u-cert
         CA2-CA2-u-p-cert CA2-EE1-p-p-cert

EE2 can also be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA2-u-u-cert CA2-EE2-u-u-cert

As you can see, in theory you can always find at least one certificate
chain to EE1 (i.e., old cert with PrintableString) or EE2 (i.e., new cert
with UTF8String). However, as I said before, we should discuss how
to amend RFC 3280 to support such certificate chaining.

Wen-Cheng Wang

----- Original Message ----- 
From: "Stefan Santesson" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>; "Stephen Kent" <[email-masked]>;
"Santoni Adriano" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, May 06, 2004 9:32 PM
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs

>
> Name rollover certificates only takes care of CA name changes.
> It doesn't solve the problem if subject names have mixed encoding in the
> forest of user certificates, while the CAs names are intact.
>
> Neither does it solve when the constraint is placed above the CA
> rollover.
>
> Finally, CA name rollover will most likely bust path validation using
> other constraining mechanisms because they may just not be recognized as
> self issued due to different name encoding.
>
> Stefan Santesson
> Program Manager, Windows Security
>

To: [email-masked], [email-masked]
Subject: Re: FW: scvp
Cc: [email-masked]

I agree with Denis about a single value policy.

I think that we have already a structure elsewhere that
is close to what can be used.  

   PolicyInformation ::= SEQUENCE {
        policyIdentifier   CertPolicyId,
        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                PolicyQualifierInfo OPTIONAL }

   CertPolicyId ::= OBJECT IDENTIFIER

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

the PolicyQualifierId would be an indidation of a
particular algorithm that needs to be performed and its
parameters. one would be "3280 path processing input"
another would be 'end entry naming comparison', etc. 

Content-class: urn:content-classes:message
Subject: RE: RFC 3280 bug in name constraints
Date: Thu, 6 May 2004 17:16:31 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, "Steve Hanna" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I agree with Sharon here.

Even though it may sound logical to always also constrain e-mail
attributes, changing the standard in this aspect will just break many
current implementations and I don't think there is enough motivation for
it.

I too just see it necessary if no rfc822Name is present. 

/Stefan

> -----Original Message-----
> From: Sharon Boeyen [mailto:[email-masked]]
> Sent: den 6 maj 2004 08:38
> To: 'Steve Hanna'; Stefan Santesson
> Cc: [email-masked]
> Subject: RE: RFC 3280 bug in name constraints
> 
> I prefer to leave 3280 as is (with Stefan's proposed change which I do
> support). The special case for checking email address in subject field
is,
> from my understanding, for backward compatibility reasons only for
> situations where the email address didn't appear in the extension. The
> subject field is a DN and should only be required to be checked if
there
> are DN name constraints (except for this backward compatibility issue
> where the exception is made).
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Steve Hanna
> Sent: Thursday, May 06, 2004 10:35 AM
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: RFC 3280 bug in name constraints
> 
> 
> I agree. In fact, I don't see why you wouldn't
> apply name constraints to an EmailAddress attribute
> in a subject DN even if there *is* an rfc822Name
> in a subject alternative name. I suggest that
> the text be revised to say:
> 
>     An rfc822 name constraint MUST be applied to an
>     attribute of type EmailAddress in the subject
>     distinguished name.
> 
> However, I'm willing to back down on this if
> people feel it's too strict. My concern is that
> a certificate with an email address in the
> subject DN prohibited by name constraints will
> be allowed because it also contains a permissible
> email address in the subject alternative name.
> I suspect many applications will not understand
> this and will accept the email address in the
> subject DN. In fact, RFC 2632 and its successor
> don't contain any warning about this.
> 
> Thanks,
> 
> Steve
> 
> Stefan Santesson wrote:
> > If someone is keeping record of bugs for future update of RFC 3280 I
> > have a small one to file about name constraints.
> >
> >
> >
> > In section 4.2.1.11, starting at bottom of page 38:
> >
> >
> >
> >    When rfc822 names are constrained, but the
> >
> >    certificate does not include a subject alternative name, the
rfc822
> >
> >    name constraint MUST be applied to the attribute of type
> > EmailAddress
> >
> >    in the subject distinguished name.
> >
> >
> >
> > Suppose/suggest that the intended meaning is:
> >
> >
> >
> >    When rfc822 names are constrained, but the certificate does not
> >
> >    include an rfc822Name in a subject alternative name extension,
the
> > rfc822
> >
> >    name constraint MUST be applied to the attribute of type
> > EmailAddress
> >
> >    in the subject distinguished name.
> >
> >
> >
> >
> >
> > Rationale:
> >
> > Why would the constraint NOT apply to EmailAddress just because
there
> > is
> > a SubjAltName extension with e.g. just some unrelated other name
> > component present?
> >
> >
> >
> > /Stefan
> >
> >
> >

Date: Thu, 6 May 2004 18:25:04 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FW: scvp
Cc: [email-masked]
Sender: [email-masked]

I agree with Denis about a single value policy.

I think that we have already a structure elsewhere that
is close to what can be used.  

   PolicyInformation ::= SEQUENCE {
        policyIdentifier   CertPolicyId,
        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                PolicyQualifierInfo OPTIONAL }

   CertPolicyId ::= OBJECT IDENTIFIER

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

the PolicyQualifierId would be an indidation of a
particular algorithm that needs to be performed and its
parameters. one would be "3280 path processing input"
another would be 'end entry naming comparison', etc. 

Date: Thu, 6 May 2004 10:44:42 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: SCVP & validation policies
Cc: [email-masked]
Sender: [email-masked]

Trevor,

I have to agree with Denis, in that it was my impression that the 
client would pass an OID to the server to express the validation 
policy to be used. The servers will, in many cases, be local to an 
enterprise, and thus it is very feasible to use a single OID to 
reference a policy that bundles all the parameters together.  In 
fact, I am not even sure that a public SCVP server is better off with 
an ala carte approach to policy specification, but I might be able to 
be convinced.

Steve

From: "Florian Oelmaier" <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, <[email-masked]>
Subject: RE: FW: scvp
Date: Fri, 7 May 2004 01:33:25 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> If a client really trusts the server like in the enterprise, 
> then the client can take the default for everything.

Thats only partly true - one of the nice things with the policy
reference is that I can choose different validation and trust settings
for different applications. Outlook, Eudora and ohter Mail programs use
the validation setting A, Mozilla, Internet Explorer and Opera the
setting B and my Web-signing application and the ERP software uses C. 

[...]

-- 
Florian Oelmaier
SyTrust

From: "Florian Oelmaier" <[email-masked]>
To: <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
Subject: FW: FW: scvp
Date: Fri, 7 May 2004 01:24:49 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

Oh.Oh. I am getting old. Pressed the wrong button and wondered why the
message does not show up on the list. It is old but it fits :)

-----Original Message-----
From: Florian Oelmaier [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2004 12:11 AM
To: 'Trevor Freeman'
Subject: RE: FW: scvp

Hello Trevor, Denis,

I personally agree with Denis - it seems to be better to reference a
policy. All the validation parameter settings can be agreed upon out of
band. Delivering the parameters within SCVP will a) be a never ending
task as people will always want another parameter for their special
use-case, b) will make the protocol even more complex in wording and
implementation and c) will make it less interoperable, as client will
expect a certain behaviour of the server when delivering certain
parameters.

So may be I am not in line with the "many groups" but I think that the
idea of a validation-policy OID is better.

Just my 0.02cp,

Florian Oelmaier
SyTrust

> 
> Hi Denis,
> There is no mandate in 3379 that a validation policy must be
> expressed with a single value. It is not clear that is any 
> value is doing so since it only raised more ambiguity. This 
> is well trod turf by many groups who have debated the merits 
> of providing suits vs. "al a carte" combinations of inputs 
> and the broader consensus is for a "al a carte". Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, May 04, 2004 3:15 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> > Hi Denis,
> > 
> > 3379 does not require that the validation policy be specified in a
> > single value.
> 
> You are playing with words. The text says:
> "most clients will simply reference a validation policy"
> 
> This means that validation policies can be referenced and
> thus parameters do 
> not need to be defined through this interface.
> 
> A simple and good reference is an OID.
> 
> > With SCVP14 a client can accept the default of the SCVP server or
> > specify a set of parameters which constitutes its 
> validation policy.
> > That is consistent with the requirements of 3379.
> 
> The specification of the set of parameters should be done through a
> different interface. This different interface can then return an OID 
> Whatever this additional interface can be, it will never be 
> rich enough to 
> pass all the details of the validation policy. Thus OIDs can 
> also be defined 
> not using this additional interface.
> 
> Denis
> 
> > Trevor
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Thursday, April 29, 2004 3:54 AM
> > To: Trevor Freeman
> > Cc: [email-masked]
> > Subject: Re: FW: scvp
> > 
> > Trevor,
> > 
> > 
> >>Hi Denis,
> > 
> > 
> >>Can you please be more specific how you think SCVP 14 does
> not comply
> >>with 3379.
> >>
> >>I can find no section in 3379 where is there a requirement that a
> >>validation policy MUST be represented as an OID.
> > 
> > 
> > There cannot be a requirement with such a level of detail, but the
> text
> > states:
> > 
> >     The protocol MUST allow the client to include
> >     these policy dependant parameters in the DPV request;
> however, it
> is
> >     expected that most clients will simply reference a validation
> policy
> >     for a given application or accept the DPV server's default
> > validation
> >     policy.
> > 
> > A simple reference is an OID.
> > 
> > FYI, I do not expect to use the "default validation policy".
> > 
> > Denis
> > 
> > 
> > 
> >>Given hiding the detail of what a policy is within an OID
> simply opens
> >>the rat hole of what change to the policy constitutes a
> change to the
> >>OID, it is less ambiguous to refer to the primary data. Once you are
> > 
> > in
> > 
> >>the business of managing state on a client, then there is
> negligible
> >>cost increase incurred in managing several data points vs. a singe
> > 
> > data
> > 
> >>point.
> >>
> >>Trevor
> >>
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[email-masked]]
> >>Sent: Tuesday, April 27, 2004 11:01 AM
> >>To: Trevor Freeman
> >>Cc: [email-masked]
> >>Subject: Re: FW: scvp
> >>
> >>Trevor,
> >>
> >>
> >>
> >>>HI Denis,
> >>>In SCVP13, the concept of validation policy was not completely in
> >>>alignment  with 3379 definition.
> >>
> >>
> >>Well, it is different and this is a major problem.
> >>
> >>
> >>
> >>>It also blurred the distinction between
> >>>validation policy and validation algorithm.
> >>
> >>
> >>This is also a majo problem.
> >>
> >>
> >>
> >>>Therefore I have defined
> >>>what each is in SCVP 14 and aligned the structures accordingly.
> >>>Section 1.3 has the following. "In SCVP, the validation policy 
> >>>comprises of an algorithm for certificate path processing and the 
> >>>input parameters to the
> >>
> >>algorithm."
> >>
> >>This does not comply with RFC 3379.
> >>
> >>
> >>
> >>>Therefore trust anchors are an input into the algorithm  and
> therefore
> >>>separate.
> >>
> >>
> >>Therefore I do not follow you.
> >>
> >> From an interface point of view the simplest validation policy is
> >>defined by an OID where all the parameters necessary to perform the 
> >>validation check
> >>are "behind" the OID. There is no need to provide any parameter
> > 
> > through
> > 
> >>the
> >>interface.
> >>
> >>When there are some parameters, then they are specific to the
> > 
> > validation
> > 
> >>policy. I have no problem to provide specific parameters
> for what is
> >>called the "default validation policy" which is only a particular
> >>validation policy
> >>among many others.
> >>
> >>Simple clients will be unable to pass any parameter but will know
> > 
> > which
> > 
> >>OIDs
> >>(for the validation policy) are appropriate for their applications.
> >>
> >>Denis
> >>
> >>
> >>
> >>>This is in alignment with 3379s definition of validation policy.
> >>>
> >>>Trevor
> >>>
> >>>-----Original Message-----
> >>>From: Denis Pinkas [mailto:[email-masked]]
> >>>Sent: Monday, April 26, 2004 1:09 AM
> >>>To: Peter Sylvester
> >>>Cc: [email-masked]; Trevor Freeman
> >>>Subject: Re: FW: scvp
> >>>
> >>>Peter and Trevor,
> >>>
> >>>I have major problems too.
> >>>
> >>>
> >>>
> >>>
> >>>>in version 13 the syntax for a Query has been changed from
> >>>>
> >>>> Query ::= SEQUENCE { 
> >>>>     queriedCerts          SEQUENCE SIZE (1..MAX) OF 
> CertReference,
> >>>>     checks                CertChecks, 
> >>>>     wantBack              WantBack, 
> >>>>     serverContextInfo [0] OCTET STRING OPTIONAL, 
> >>>>     valPolicy         [1] ValidationPolicy OPTIONAL, 
> >>>>     validityTime      [2] GeneralizedTime OPTIONAL, 
> >>>>     trustAnchors      [3] TrustAnchors OPTIONAL, 
> >>>>     intermediateCerts [4] CertBundle OPTIONAL, 
> >>>>     revInfos          [5] RevocationInfos OPTIONAL, 
> >>>>     queryExtensions   [6] Extensions OPTIONAL } 
> >>>
> >>>
> >>>In this structure trustAnchors was more or less an alternative to
> >>>valPolicy.
> >>>
> >>>In fact, IF the valPolicy is the default policy, THEN additional
> >>>parameters MUST be provided. So the structure below does 
> not fit as
> >>>well.
> >>>
> >>>This leads to have the two following elements:
> >>>
> >>>    valPolicy               ValidationPolicy,
> >>>    paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
> >>>
> >>>where the first one is mandatory and the second one optional.
> >>>
> >>>
> >>>
> >>>
> >>>>to
> >>>>
> >>>>  Query ::= SEQUENCE { 
> >>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF 
> CertReference,
> >>>
> >>>
> >>>>    checks                  CertChecks, 
> >>>>    wantBack                WantBack, 
> >>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
> >>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
> >>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
> >>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
> >>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
> >>>>    valAlgorithm            ValidationAlgorithm, 
> >>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
> >>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
> >>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
> >>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
> >>>>    revInfos            [4] RevocationInfos OPTIONAL, 
> >>>>    queryExtensions     [5] Extensions OPTIONAL } 
> >>>
> >>>
> >>>I would thus propose to have something like:
> >>>
> >>>Query ::= SEQUENCE {
> >>>        queriedCerts            SEQUENCE SIZE (1..MAX) OF
> >>>CertReference,
> >>>        checks                  CertChecks,
> >>>        wantBack                WantBack,
> >>>        requestRefHash          BOOLEAN DEFAULT TRUE,
> >>>        serverContextInfo       OCTET STRING OPTIONAL,
> >>>        validityTime            GeneralizedTime OPTIONAL,
> >>>        includePolResponse      BOOLEAN DEFAULT FALSE,
> >>>        valPolicy               ValidationPolicy,
> >>>        paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
> >>>        intermediateCerts   [1] CertBundle OPTIONAL,
> >>>        revInfos            [2] RevocationInfos OPTIONAL,
> >>>        queryExtensions     [3] Extensions OPTIONAL }
> >>>
> >>>and then something like:
> >>>
> >>>   ParamsDefValPolicy :: = SEQUENCE {
> >>>       trustAnchors                  TrustAnchors,
> >>>       endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
> >>>OPTIONAL,
> >>>       inhibitPolMap                 BOOLEAN DEFAULT FALSE,
> >>>       caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
> >>>OPTIONAL }
> >>>
> >>>Denis
> >>>
> >>>
> >>>
> >>>
> >>>>I am not sure whether I am the only person unable to construct a
> >>>
> >>>parser.
> >>>
> >>>
> >>>
> >>>>in version 14 an aditional flag has been added which is not
> available
> >>>
> >>>in the
> >>>
> >>>
> >>>
> >>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
> >>>
> > validation
> > 
> >>>>algorithms, or just to some of them, e.g,. the default
> name matching
> >>>
> >>>one?
> >>>
> >>>
> >>>
> >>>>  Query ::= SEQUENCE { 
> >>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF 
> CertReference,
> >>>
> >>>
> >>>>    checks                  CertChecks, 
> >>>>    wantBack                WantBack, 
> >>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
> >>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
> >>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
> >>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
> >>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
> >>>>    isCA                    BOOLEAN DEFAULT FALSE, 
> >>>>    valAlgorithm            ValidationAlgorithm, 
> >>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
> >>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
> >>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
> >>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
> >>>>    revInfos            [4] RevocationInfos OPTIONAL, 
> >>>>    keyUsage            [5] KeyUsage OPTIONAL, 
> >>>>    extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
> >>>>    queryExtensions     [7] Extensions OPTIONAL  
> >>>>    producedAt          [8] GeneralizedTime OPTIONAL} 
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> > 
> > 
> > 
> 
> 
> 
> 

Date: Thu, 6 May 2004 19:05:53 -0400
To: Steve Hanna <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: RFC 3280 bug in name constraints
Cc: Stefan Santesson <[email-masked]>, Sharon Boeyen <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Steve,

Thanks for the thoughtful analysis.  I think you make a good argument 
for why it can be dangerous for one to apply an rfc822name constraint 
to a sub alt name but not an e-mail attribute in a subject name, and 
how the combination might arise.

Steve

Date: Thu, 06 May 2004 17:57:16 -0400
From: Steve Hanna <[email-masked]>
Subject: Re: RFC 3280 bug in name constraints
To: Stephen Kent <[email-masked]>
Cc: Stefan Santesson <[email-masked]>, Sharon Boeyen <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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

Here's a practical example where this problem
might arise. Assume that two companies, A and B,
have cross-certified (maybe through a bridge CA,
maybe directly). The cross certificate from A to B
includes a name constraint of type rfc822Name
with permittedSubtrees of b.com. The CA for B
(or perhaps a rebellious or poorly managed
subsidiary CA) issues a certificate to an
individual with an EmailAddress attribute
with the value "[email-masked]" in the subject DN
and a subject alt name of type rfc822Name
with the value "[email-masked]".

Under the current text in RFC 3280 and under
Stefan's proposed revised text, a relying
party whose trust anchor is A will consider
this certificate perfectly valid. Unless their
email software is smart enough to know that
an EmailAddress attribute in the subject DN
is not checked for name constraints when
there's also a subject alt name and therefore
the EmailAddress attribute must be ignored,
the email software will be glad to verify
email claiming to be from [email-masked] if the
signature can be verified with this certificate.

Why is this a problem? Because the name constraints
extension in the cross certificate was supposed
to prevent relying parties in A from accepting
certificates from B when an email address outside
of b.com as the subject DN or subject alt name.

I have cc'd this email to the smime WG. Maybe they
will tell me not to worry. Email clients are smart
enough to know that if a valid certificate contains
a subject alt name, then the EmailAddress attribute
in the subject DN cannot be trusted. But I don't
think email clients do this check. I certainly can't
find any language in RFC 2632 and its successor warning
people to do this.

Either RFC 3280 should consider the cert described
above as invalid or RFC 2632 should warn email developers
to ignore an EmailAddress attribute in the subject DN
if the certificate contains a subject alt name. Otherwise,
I think we have a security hole. Given the choice between
these two options, I'd rather change RFC 3280. Why?
First, I don't think that cert should be valid. Second,
it's usually easier to change the path validation code
and get that deployed (via an OS patch or equivalent)
than to change the email client code.

Thanks,

Steve

Stephen Kent wrote:
> At 5:16 PM +0100 5/6/04, Stefan Santesson wrote:
> 
>> I agree with Sharon here.
>>
>> Even though it may sound logical to always also constrain e-mail
>> attributes, changing the standard in this aspect will just break many
>> current implementations and I don't think there is enough motivation for
>> it.
>>
>> I too just see it necessary if no rfc822Name is present.
>>
>> /Stefan
>>
> 
> This is a slightly murky area. The e-mail address attribute is one that 
> we deprecate in 3280.  It is a non-standard way of representing this 
> data; it was widely used in v1 certs, but ought to be scrapped for v3 
> certs. however, is it likely that a CA who goes to the trouble to 
> include the name constraints extension, and who explicitly includes an 
> rfc822name as an alt name, would also have the email address DN 
> attribute as well?  I just wonder if this potential collision is at all 
> likely?
> 
> 
> Steve

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

--------------ms000301050500030008070709--

Date: Thu, 6 May 2004 16:23:24 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: FW: scvp
Cc: "Peter Sylvester" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 11:33 AM -0700 5/6/04, Trevor Freeman wrote:
>If a client really trusts the server like in the enterprise, then the
>client can take the default for everything.

That seems unlikely to me, not because of trust issues, but because 
the validation policy may (should?) be application specific and thus 
the client may need to assert a per-application policy to ensure that 
the validation process is appropriate to the application.

>  What I am suggesting is that
>there could be a long or short had way of expressing the policy and a
>client can choose either. Given we have a well know list of parameters,
>we can pass them directly or indirectly via a hash. Explicit passing is
>more robust since it is unambiguous and requires no configuration on the
>part of the server. The client also has a fallback in the event he
>server does not recognize the shorthand. I do not buy the argument that
>using a shorthand is easer to manage. You MUST at some point define the
>policy in terms of the validation input parameters and that definition
>can just as easily be consumed by the client as the server. So all I see
>is the shorthand saves bandwidth - which is a minimal gain.

The definition of the parameters is done via a separate protocol, and 
is a management activity that the client may never have to employ. 
So, on that regard, I disagree that the client needs to "consume" 
these parameters.

I would rather see a set of parameters referenced via an OID, than 
via a hash of the parameters, to keep things simpler.

Steve

Date: Thu, 6 May 2004 16:27:58 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SCVP & validation policies
Cc: <[email-masked]>
Sender: [email-masked]

At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>Hi Steve,
>If you want to have a shorthand notation for a validation policy, given
>we have a finite set of parameters, the I don't see the value of
>indirection via an OID. Using a hash of the set of inputs provides a way
>of expressing the same thing without introducing ambiguity of does both
>parties have a common understating of that this means. At some point
>someone has to define the policy in terms of the 3280 input parameters.
>That definition is just as applicable and consumable by the client as a
>server therefore what did we gain from the shorthand notation? It would
>be pretty trivial to define some XML which would allow that set of
>validation parameters to be imported by any SCVP entity.
>Trevor

Trevor,

It is not indirection via an OID, it is identification via an OID. 
Clients never have to be aware of the parameters if we use an OID, 
and simplification of clients is one of the goals of SCVP. So I 
cannot agree with your comment that clients have to be able to 
consume these parameters.

Given that as a basis, it seems that we are debating whether to use 
OIDs or to create some other form of identifier via hashing 
parameters. I don't see the latter as attractive, since it requires 
additional specification of the canonicalization and encoding of the 
parameters to ensure consistency in hash computation between client 
and server.

Steve

Date: Thu, 6 May 2004 16:16:35 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: RFC 3280 bug in name constraints
Cc: "Sharon Boeyen" <[email-masked]>, "Steve Hanna" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 5:16 PM +0100 5/6/04, Stefan Santesson wrote:
>I agree with Sharon here.
>
>Even though it may sound logical to always also constrain e-mail
>attributes, changing the standard in this aspect will just break many
>current implementations and I don't think there is enough motivation for
>it.
>
>I too just see it necessary if no rfc822Name is present.
>
>/Stefan
>

This is a slightly murky area. The e-mail address attribute is one 
that we deprecate in 3280.  It is a non-standard way of representing 
this data; it was widely used in v1 certs, but ought to be scrapped 
for v3 certs. however, is it likely that a CA who goes to the trouble 
to include the name constraints extension, and who explicitly 
includes an rfc822name as an alt name, would also have the email 
address DN attribute as well?  I just wonder if this potential 
collision is at all likely?

Steve

Content-class: urn:content-classes:message
Subject: RE: SCVP & validation policies
Date: Thu, 6 May 2004 12:10:59 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Steve,
If you want to have a shorthand notation for a validation policy, given
we have a finite set of parameters, the I don't see the value of
indirection via an OID. Using a hash of the set of inputs provides a way
of expressing the same thing without introducing ambiguity of does both
parties have a common understating of that this means. At some point
someone has to define the policy in terms of the 3280 input parameters.
That definition is just as applicable and consumable by the client as a
server therefore what did we gain from the shorthand notation? It would
be pretty trivial to define some XML which would allow that set of
validation parameters to be imported by any SCVP entity.
Trevor

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Thursday, May 06, 2004 7:45 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: SCVP & validation policies

Trevor,

I have to agree with Denis, in that it was my impression that the 
client would pass an OID to the server to express the validation 
policy to be used. The servers will, in many cases, be local to an 
enterprise, and thus it is very feasible to use a single OID to 
reference a policy that bundles all the parameters together.  In 
fact, I am not even sure that a public SCVP server is better off with 
an ala carte approach to policy specification, but I might be able to 
be convinced.

Steve

From: Sharon Boeyen <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>, Stefan Santesson <[email-masked]>
Cc: [email-masked]
Subject: RE: RFC 3280 bug in name constraints
Date: Thu, 6 May 2004 14:42:25 -0400 
Sender: [email-masked]

Apparently some could not read the message I sent earlier, so here is a
resend. 

I prefer to leave 3280 as is (with Stefan's proposed change which I do
support). The special case for checking email address in subject field is,
from my understanding, for backward compatibility reasons only for
situations where the email address didn't appear in the extension. The
subject field is a DN and should only be required to be checked if there are
DN name constraints (except for this backward compatibility issue where the
exception is made).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Steve Hanna
Sent: Thursday, May 06, 2004 10:35 AM
To: Stefan Santesson
Cc: [email-masked]
Subject: Re: RFC 3280 bug in name constraints

I agree. In fact, I don't see why you wouldn't
apply name constraints to an EmailAddress attribute
in a subject DN even if there *is* an rfc822Name
in a subject alternative name. I suggest that
the text be revised to say:

    An rfc822 name constraint MUST be applied to an
    attribute of type EmailAddress in the subject
    distinguished name.

However, I'm willing to back down on this if
people feel it's too strict. My concern is that
a certificate with an email address in the
subject DN prohibited by name constraints will
be allowed because it also contains a permissible
email address in the subject alternative name.
I suspect many applications will not understand
this and will accept the email address in the
subject DN. In fact, RFC 2632 and its successor
don't contain any warning about this.

Thanks,

Steve

Stefan Santesson wrote:
> If someone is keeping record of bugs for future update of RFC 3280 I
> have a small one to file about name constraints.
> 
>  
> 
> In section 4.2.1.11, starting at bottom of page 38:
> 
>  
> 
>    When rfc822 names are constrained, but the
> 
>    certificate does not include a subject alternative name, the rfc822
> 
>    name constraint MUST be applied to the attribute of type 
> EmailAddress
> 
>    in the subject distinguished name.
> 
>  
> 
> Suppose/suggest that the intended meaning is:
> 
>  
> 
>    When rfc822 names are constrained, but the certificate does not
> 
>    include an rfc822Name in a subject alternative name extension, the 
> rfc822
> 
>    name constraint MUST be applied to the attribute of type 
> EmailAddress
> 
>    in the subject distinguished name.
> 
>  
> 
>  
> 
> Rationale:
> 
> Why would the constraint NOT apply to EmailAddress just because there 
> is
> a SubjAltName extension with e.g. just some unrelated other name 
> component present?
> 
>  
> 
> /Stefan
> 
>  
> 

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Thu, 6 May 2004 11:33:18 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

If a client really trusts the server like in the enterprise, then the
client can take the default for everything. What I am suggesting is that
there could be a long or short had way of expressing the policy and a
client can choose either. Given we have a well know list of parameters,
we can pass them directly or indirectly via a hash. Explicit passing is
more robust since it is unambiguous and requires no configuration on the
part of the server. The client also has a fallback in the event he
server does not recognize the shorthand. I do not buy the argument that
using a shorthand is easer to manage. You MUST at some point define the
policy in terms of the validation input parameters and that definition
can just as easily be consumed by the client as the server. So all I see
is the shorthand saves bandwidth - which is a minimal gain.
Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Thursday, May 06, 2004 11:04 AM
To: [email-masked]; [email-masked]; Trevor Freeman
Cc: [email-masked]
Subject: RE: FW: scvp

> 
> If we want to go down the route of providing a shorthand notation for
a
> validation policy, using an OID just opens up ambiguity. We are
assuming
> both client and server have a common understating of both - which add
> additional management overhead.

A dumb client may have no understanding of a policy, it just wan't
some information concerning the usage of a cert in its particular
context. In an extreme case, just a yes/no answer is good,
and the protocol should allow to have such a minimal exchange.

You are describing a way that a client MUST always provide actual
parameters. This seems to me unnecessary overhead at the client. 

If the actual policy parameters are required to be known by the
client, the server can return then in the response, so that they
can be logged by the client if necessary, or transferred to another
relying party, etc. 

We assume that the application of the policy is under the responsibility
of the server, it seems rather natural to me that in case that
the response could be questioned in the future, the server indicated
what it had done. or, the informations gets transferred only once.

>                              It seems like yesterday we had the
> discussion on whether a certificate policy should also have a hash so
> the RP could tell if the policy had changed. If we truly want a
> shorthand notation to a policy then using a hash over the set of input
> parameters provides an unambiguous statement of what is required.

It is absolutely possible that the policy details at the server
will change without a need for a client to get informed, at least
in an enterprise internal  environment. It is at the server side
where all decisions are made for dumb clients.

If the client has a single application context, then a
request should be possible to contain just the reference to
the cert or the cert, and in an extreme, even the policy could be
derived at the server if the client can be identified and authenticated,
in this case the client configuration is minimal.

Peter 

Date: Thu, 6 May 2004 20:03:53 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: FW: scvp
Cc: [email-masked]
Sender: [email-masked]

> 
> If we want to go down the route of providing a shorthand notation for a
> validation policy, using an OID just opens up ambiguity. We are assuming
> both client and server have a common understating of both - which add
> additional management overhead.

A dumb client may have no understanding of a policy, it just wan't
some information concerning the usage of a cert in its particular
context. In an extreme case, just a yes/no answer is good,
and the protocol should allow to have such a minimal exchange.

You are describing a way that a client MUST always provide actual
parameters. This seems to me unnecessary overhead at the client. 

If the actual policy parameters are required to be known by the
client, the server can return then in the response, so that they
can be logged by the client if necessary, or transferred to another
relying party, etc. 

We assume that the application of the policy is under the responsibility
of the server, it seems rather natural to me that in case that
the response could be questioned in the future, the server indicated
what it had done. or, the informations gets transferred only once.

>                              It seems like yesterday we had the
> discussion on whether a certificate policy should also have a hash so
> the RP could tell if the policy had changed. If we truly want a
> shorthand notation to a policy then using a hash over the set of input
> parameters provides an unambiguous statement of what is required.

It is absolutely possible that the policy details at the server
will change without a need for a client to get informed, at least
in an enterprise internal  environment. It is at the server side
where all decisions are made for dumb clients.

If the client has a single application context, then a
request should be possible to contain just the reference to
the cert or the cert, and in an extreme, even the policy could be
derived at the server if the client can be identified and authenticated,
in this case the client configuration is minimal.

Peter 

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Thu, 6 May 2004 10:22:37 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

If we want to go down the route of providing a shorthand notation for a
validation policy, using an OID just opens up ambiguity. We are assuming
both client and server have a common understating of both - which add
additional management overhead. It seems like yesterday we had the
discussion on whether a certificate policy should also have a hash so
the RP could tell if the policy had changed. If we truly want a
shorthand notation to a policy then using a hash over the set of input
parameters provides an unambiguous statement of what is required.
Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: Thursday, May 06, 2004 9:25 AM
To: Trevor Freeman; [email-masked]
Cc: [email-masked]
Subject: Re: FW: scvp

I agree with Denis about a single value policy.

I think that we have already a structure elsewhere that
is close to what can be used.  

   PolicyInformation ::= SEQUENCE {
        policyIdentifier   CertPolicyId,
        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                PolicyQualifierInfo OPTIONAL }

   CertPolicyId ::= OBJECT IDENTIFIER

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

the PolicyQualifierId would be an indidation of a
particular algorithm that needs to be performed and its
parameters. one would be "3280 path processing input"
another would be 'end entry naming comparison', etc. 

Date: Thu, 06 May 2004 17:47:45 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Sender: [email-masked]

Steve Hanna wrote:

> A better solution is to require (or at least recommend)
> the ability to properly compare PrintableString and
> UTF8String encodings.

This still leave to the CA the task of enforcing the user certs only use 
PrintableString or UTF8String.
Either by refusing requests with other encodings or converting them.
Given the current text of RFC3280 this is probably the best choice.

But an application like openssl is currently shipped with the default of 
authorizing either of PrintableString and T61String and nothing else.
If some people do emit T61String (it does happen at least on a small 
scale), they'll need to be able to compare to UTF8String.
And this does require actual convertion whereas equality comparison of 
PrintableString and UTF8String could be done by just ignoring the asn1 
type tag.
The above reminds me how important it is that implementers correctly 
reject invalid UTF-8 sequences, and that it's not garanteed to happen.

From: Sharon Boeyen <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>, Stefan Santesson <[email-masked]>
Cc: [email-masked]
Subject: RE: RFC 3280 bug in name constraints
Date: Thu, 6 May 2004 11:37:57 -0400 
Sender: [email-masked]

From: Sharon Boeyen <[email-masked]>
To: [email-masked]
Subject: RE: Cross certificate format
Date: Thu, 6 May 2004 11:34:16 -0400 
Sender: [email-masked]

I'd also like to clarify that the constraints that input to the path
validation process (e.g. initial-policy-mapping-inhibit,
initial-explicit-policy etc) are not tied necessarily to the trust anchor
but are tied to an instance of path validation conducted by the relying
party. It may be the relying party and not CA who happens to be the trust
anchor that determines these constraints. They are just additional inputs to
the process, as is the trust anchor public key. The same validation engine
may have different constraints on instances of path validation that use the
same trust anchor public key. Also, the same set of constraints can apply to
instances of validation that use different trust anchors. Different users,
different apps and even different transactions can have different
constraints even though they may happen to use the same trust anchor. While
it is true that including some extensions in a self-signed might be one way
to convey constraints that could then be extracted and provided as the
relevant inputs to the validation process, this is certainly not the only
way to convey initialization constraint values for a RP. Also, I believe it
is a very limiting way because then the constraints are tied to all
validations that occur with that key by all RPs (assuming all RPs used that
scheme to initialize their path validation variables). The mechanisms that
determine those inputs to the path validation process (including which trust
anchor public key to use, process are outside the scope of X.509. X.509
provides the mechanism (path validation variable initialization) to set the
constraints once the RP has determined what they are to be. 

On the nameConstraints issue, there is work underway in X.509 that will add
one more input to the path validation process to enable nameConstraints to
be imposed at initialization time just as other constraints can already.
Similar to the other constraints, no single value of initialization
constraints is tied necessarily to all uses of a trust anchor public key.  

On the earlier discussion of processing extensions in self-signed certs. I
believe X.509 and 3280 are completely consistent here in pointing out that
the self-signed cert is not part of the path (but may be a convenient way
for a CA to convey its public key). See clause 8.1.5 of X.509 for the
relevant text "For purposes of path validation, self-issued certificates of
type a) are verified with the public key contained in them, and if they are
encountered in the path, they shall be ignored." As a result of Defect
Report 285, that same point is the basic certificate checks in the path
processing alogithm in X.509. In the first paragraph of 10.5.1, you'll find
the sentence "Self-signed certificates, if encountered in the path are
ignored."

As for the checking of whether a self-signed cert has basic constraints with
CA set to TRUE etc, that is part of the checking that could be done to place
trust in the fact that certified key should be used as an input to the path
validation process. However, because X.509 does not mandate any scheme for
conveying these keys to users, it obviously doesn't mandate any checks on
those schemes. Any checking along these lines is outside the scope of the
path validation process because it would be done before the process is
initialized with that key.

Sorry for the lengthy message
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Steve Hanna
Sent: Wednesday, May 05, 2004 5:26 PM
To: Tom Gindin
Cc: Santosh Chokhani; [email-masked]
Subject: Re: Cross certificate format

See section 6.2 of RFC 3280, which says:

    ...  An implementation that supports multiple trust anchors
    MAY augment the algorithm presented in section 6.1 to further limit
    the set of valid certification paths which begin with a particular
    trust anchor.  For example, an implementation MAY modify the
    algorithm to apply name constraints to a specific trust anchor during
    the initialization phase, or the application MAY require the presence
    of a particular alternative name form in the end entity certificate,
    or the application MAY impose requirements on application-specific
    extensions.  Thus, the path validation algorithm presented in section
    6.1 defines the minimum conditions for a path to be considered valid.

There's no need to change RFC 3280 to allow
path validation implementations to apply
name constraints to trust anchors. That's
explicitly discussed in this section of the RFC.

Thanks,

Steve

Tom Gindin wrote:
>         Santosh:
> 
>         Of course, defining a trust anchor implies that the RP trusts 
> the
> anchor's public key as an issuer for at least some purposes.  RFC 3280, in

> the parts of section 6.1.2 I cited, appears to forbid those state 
> variables from being set from information defined by the RP or stored with

> the trust anchor.  This is consistent with its statements in 6.1.1 d which

> permit self-signed certificates but say nothing about other CA 
> certificates.  As is probably clear to everyone reading this thread, I 
> think that this is not an ideal set of suggestions.
>         The current standard does contain some constraints on the trust 
> anchor (notably inhibit-policy-mapping), but neither name constraints nor 
> basic constraints.  I consider this an anomaly.  If I had free rein in 
> rewording pieces of RFC 3280 section 6.1, I would change this wording to 
> allow CA certificates along with self-signed ones as anchors and create 
> extra optional (and optional to support) fields to be set from the trust 
> anchor.
>         I don't think that this is particularly inconsistent with general 
> security principles, or with any part of X.509 with which I am familiar. 
> It does represent an extension of RFC 3280 section 6, and it is only 
> backward compatible with it, so it may be out of scope.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> Sent by: [email-masked]
> 05/01/2004 06:46 PM
> 
>  
>         To:     <[email-masked]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> The standard does not require you to check how you initialize the
> variables.
> You can get these from the cross certificate or from some configuration.
> 
> The basic point is that you trust the public key.  How you constrain 
> it is not address by the standard, where as if the same certificate 
> appeared in a path, you have to apply the constraints or be not 
> compliant with the standard.
> 
> You obviously do not believe in re-incarnation.  Just kidding......
> 
> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Saturday, May 01, 2004 6:31 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: RE: Cross certificate format
> 
> 
>         Santosh:
> 
>         It is well known that trust in a trust anchor can be defined 
> in a
> variety of ways.  However, there is every reason to think that an RP may 
> constrain that trust and that the constraints he may apply include those 
> which an issuer CA may apply to a subordinate one. The wording of RFC 3280

> 
> section 6.2's first paragraph is an example of this.
>         My comments about the meaning of a trust anchor are not purely
> theoretical.  If a cross certificate is used to represent a trust anchor, 
> the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
> (RFC 3280 6.1.2 c) could easily be set from the contents of a 
> NameConstraints extension, and the variable max_path_length (RFC 3280 
> 6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
> today, these variables are set to constants (although that interpretation 
> is not absolutely clear for permitted_subtrees).  In fact, they are three 
> of the four variables which are set to constants during initialization.
>         If permitted subtrees were set to a list of attributes, the 
> validation process would fail if the anchor CA or a CA it certified went 
> beyond the restrictions of those attributes.  Likewise, if the excluded 
> subtrees were set to a list of attributes, the validation process would 
> fail if the anchor CA or a CA it certified went used values matching any 
> of those attributes.  I do not believe that I am arguing against Galileo.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> Sent by: [email-masked]
> 04/29/2004 11:12 PM
> 
>  
>         To:     <[email-masked]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> The basic point (at the risk of repeating myself) is that a CA 
> certificate or a self-signed certificate can be used as a means to 
> provide trust anchor information.  In that case, there is no need to 
> check signature or anything.
> 
> But, when the CA certificate is a certificate in the certificate path,
> X.509
> logic kicks in.
> 
> This is consistent with X.509, 3280 and general security principles 
> since the trust in a trust anchor can be derived through any number of 
> means.
> 
> If you do not agree, feel free to argue against the definitions and
> Galileo
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On
> Behalf Of Tom Gindin
> Sent: Thursday, April 29, 2004 8:43 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: RE: Cross certificate format
> 
> 
> 
>         Santosh:
> 
>         I don't think that a CA certificate and a trust anchor are as 
> much
> 
> 
> different things as different uses for the same thing.  They are both
> identifiers of issuers which bind a public key to an issuer name, and it 
> is perfectly appropriate for any CA certificate to represent a trust 
> anchor.  I also do not see why such things as name constraints on a trust 
> anchor are inappropriate.  It is perfectly true that verifying a trust 
> anchor's certificate, when issued by another CA (who may not be trusted) 
> is a pointless operation.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> Sent by: [email-masked]
> 04/27/2004 09:14 AM
> 
>  
>         To:     <[email-masked]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> My point is that even if the trust anchor is a self-signed 
> certificate,
> all
> you need to do is extract the required information.  There is no need to
> examine anything.
> 
> Cross certificate and trust anchor are very different things.  An 
> element
> of
> the cross certificate pair is nothing but an intermediate CA certificate 
> in
> a certification path.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On
> Behalf Of Tom Gindin
> Sent: Tuesday, April 27, 2004 7:33 AM
> To: Santosh Chokhani
> Cc: [email-masked]; [email-masked]
> Subject: RE: Cross certificate format
> 
> 
> 
>         Santosh:
> 
>         Of course, you are right that RFC 3280 6.1.1 d permits trust
> anchor information to be provided outside a certificate.  If it is so, no 
> checks of the sort I indicated can be performed.  It also says that it can

> 
> 
> 
> be provided as "a self-signed certificate", with no further 
> qualification.
> 
> 
> 
>  I do think it is somewhat odd that a self-signed certificate with
> KeyUsage set to typical EE values would be considered a valid issuer as a 
> trust anchor while a cross certificate would not.  You can always extract 
> the needed anchor information from a cross-certificate, of course.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> Sent by: [email-masked]
> 04/26/2004 08:51 AM
> 
>  
>         To:     <[email-masked]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> My reading of 3280 and X.509 is that a trust anchor need not even be a 
> certificate.  Thus, no checks need to be performed on a trust anchor 
> at all. You get the DN, public key, algorithm OID, and parameters (if 
> applicable) from a trust anchor.  Any checks are gratuitous and not 
> required by either standard.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On
> Behalf Of Tom Gindin
> Sent: Sunday, April 25, 2004 7:06 PM
> To: Jean-Marc Desperrier
> Cc: [email-masked]
> Subject: Re: Cross certificate format
> 
> 
> 
>         Jean-Marc:
> 
>         RFC 3280 doesn't say that anywhere.  It does say that you 
> don't
> need to validate the trust anchor as part of the path, but it isn't clear 
> from the text that a v1 certificate is acceptable as a trust anchor - and 
> it certainly isn't clear that a v1 certificate is acceptable as an issuer 
> if it is a trust anchor while a v3 certificate with KeyUsage= { 
> DigitalSignature, keyEncipherment } is not acceptable as an issuer even if

> 
> 
> 
> 
> it is a trust anchor.
>         I believe that the correct rules for versions are something 
> like
> the following: a certificate issued by a trust anchor which is represented

> 
> 
> 
> 
> by a certificate is verifiable if the anchor certificate is either a 
> v1
> certificate or a v3 certificate with the CA flag present in the 
> basicConstraints extension.  If the anchor certificate is a v3 certificate

> 
> 
> 
> 
> with the KeyUsage extension present, it is only a valid issuer 
> certificate
> 
> 
> 
> 
> if keyCertSign is set.
> 
>         Tom Gindin
> 
> 
> 
> 
> 
> Jean-Marc Desperrier <[email-masked]>
> Sent by: [email-masked]
> 04/21/2004 03:42 PM
> 
>  
>         To:     [email-masked]
>         cc: 
>         Subject:        Re: Cross certificate format
> 
> 
> 
> 
> Tom Gindin wrote:
> 
> 
>>       RFC 3280 does not support the use of v1 self-signed 
>>certificates,
> 
> 
>>which contain no extensions at all (see the text of RFC 3280's
>>basicConstraints section).  However, a number of public CA's still have 
>>them.
>>
>>
> 
> Applications implementing the path validation algorithm of RFC3280 
> MUST
> accept them when they are used as trust anchors.
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Date: Thu, 06 May 2004 16:47:10 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
Subject: Re: FW: scvp
Sender: [email-masked]

Trevor,

> Hi Denis,

> There is no mandate in 3379 that a validation policy must be expressed
> with a single value. 

"The protocol MUST allow the client to include these policy dependant 
parameters in the DPV request; however, it is expected that most clients 
will simply reference a validation policy."

The "however" mandates that a validation policy must also be expressed
with a single value.

I do not understand your resistance against a single value.
The following strcture could accomodate both approaches:

    ValPolicy  ::=  SEQUENCE  {
         valPolId      OBJECT IDENTIFIER,
         valPolValue   OCTET STRING  OPTIONAL }

The valPolValue would be dependent upon the OID of the valPolId and the 
structure of the valPolValue in the case of the "default policy" would be 
defined in the current document.

Other structures could be defined in other documents.

Denis

 > for a given application or accept the DPV server's default
 > validation policy.

> It is not clear that is any value is doing so since
> it only raised more ambiguity. This is well trod turf by many groups who
> have debated the merits of providing suits vs. "al a carte" combinations
> of inputs and the broader consensus is for a "al a carte".
> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Tuesday, May 04, 2004 3:15 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> 
>>Hi Denis,
>>
>>3379 does not require that the validation policy be specified in a
>>single value. 
> 
> 
> You are playing with words. The text says:
> "most clients will simply reference a validation policy"
> 
> This means that validation policies can be referenced and thus
> parameters do 
> not need to be defined through this interface.
> 
> A simple and good reference is an OID.
> 
> 
>>With SCVP14 a client can accept the default of the SCVP
>>server or specify a set of parameters which constitutes its validation
>>policy. That is consistent with the requirements of 3379.
> 
> 
> The specification of the set of parameters should be done through a 
> different interface. This different interface can then return an OID 
> Whatever this additional interface can be, it will never be rich enough
> to 
> pass all the details of the validation policy. Thus OIDs can also be
> defined 
> not using this additional interface.
> 
> Denis
> 
> 
>>Trevor
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[email-masked]] 
>>Sent: Thursday, April 29, 2004 3:54 AM
>>To: Trevor Freeman
>>Cc: [email-masked]
>>Subject: Re: FW: scvp
>>
>>Trevor,
>>
>>
>>
>>>Hi Denis,
>>
>>
>>>Can you please be more specific how you think SCVP 14 does not comply
>>>with 3379.
>>>
>>>I can find no section in 3379 where is there a requirement that a
>>>validation policy MUST be represented as an OID. 
>>
>>
>>There cannot be a requirement with such a level of detail, but the
> 
> text
> 
>>states:
>>
>>    The protocol MUST allow the client to include
>>    these policy dependant parameters in the DPV request; however, it
> 
> is
> 
>>    expected that most clients will simply reference a validation
> 
> policy
> 
>>    for a given application or accept the DPV server's default
>>validation
>>    policy.
>>
>>A simple reference is an OID.
>>
>>FYI, I do not expect to use the "default validation policy".
>>
>>Denis
>>
>>
>>
>>
>>>Given hiding the detail of what a policy is within an OID simply opens
>>>the rat hole of what change to the policy constitutes a change to the
>>>OID, it is less ambiguous to refer to the primary data. Once you are
>>
>>in
>>
>>
>>>the business of managing state on a client, then there is negligible
>>>cost increase incurred in managing several data points vs. a singe
>>
>>data
>>
>>
>>>point.
>>>
>>>Trevor
>>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[email-masked]] 
>>>Sent: Tuesday, April 27, 2004 11:01 AM
>>>To: Trevor Freeman
>>>Cc: [email-masked]
>>>Subject: Re: FW: scvp
>>>
>>>Trevor,
>>>
>>>
>>>
>>>
>>>>HI Denis,
>>>>In SCVP13, the concept of validation policy was not completely in
>>>>alignment  with 3379 definition. 
>>>
>>>
>>>Well, it is different and this is a major problem.
>>>
>>>
>>>
>>>
>>>>It also blurred the distinction between
>>>>validation policy and validation algorithm. 
>>>
>>>
>>>This is also a majo problem.
>>>
>>>
>>>
>>>
>>>>Therefore I have defined
>>>>what each is in SCVP 14 and aligned the structures accordingly.
>>>>Section 1.3 has the following.
>>>>"In SCVP, the validation policy comprises of an algorithm for
>>>>certificate path processing and the input parameters to the
>>>
>>>algorithm."
>>>
>>>This does not comply with RFC 3379.
>>>
>>>
>>>
>>>
>>>>Therefore trust anchors are an input into the algorithm  and
>>>
> therefore
> 
>>>>separate.
>>>
>>>
>>>Therefore I do not follow you.
>>>
>>>From an interface point of view the simplest validation policy is
>>>defined 
>>>by an OID where all the parameters necessary to perform the validation
>>>check 
>>>are "behind" the OID. There is no need to provide any parameter
>>
>>through
>>
>>
>>>the 
>>>interface.
>>>
>>>When there are some parameters, then they are specific to the
>>
>>validation
>>
>>
>>>policy. I have no problem to provide specific parameters for what is
>>>called 
>>>the "default validation policy" which is only a particular validation
>>>policy 
>>>among many others.
>>>
>>>Simple clients will be unable to pass any parameter but will know
>>
>>which
>>
>>
>>>OIDs 
>>>(for the validation policy) are appropriate for their applications.
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>>This is in alignment with 3379s definition of validation policy.
>>>>
>>>>Trevor
>>>>
>>>>-----Original Message-----
>>>>From: Denis Pinkas [mailto:[email-masked]] 
>>>>Sent: Monday, April 26, 2004 1:09 AM
>>>>To: Peter Sylvester
>>>>Cc: [email-masked]; Trevor Freeman
>>>>Subject: Re: FW: scvp
>>>>
>>>>Peter and Trevor,
>>>>
>>>>I have major problems too.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>in version 13 the syntax for a Query has been changed from
>>>>>
>>>>>Query ::= SEQUENCE { 
>>>>>    queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>>>>    checks                CertChecks, 
>>>>>    wantBack              WantBack, 
>>>>>    serverContextInfo [0] OCTET STRING OPTIONAL, 
>>>>>    valPolicy         [1] ValidationPolicy OPTIONAL, 
>>>>>    validityTime      [2] GeneralizedTime OPTIONAL, 
>>>>>    trustAnchors      [3] TrustAnchors OPTIONAL, 
>>>>>    intermediateCerts [4] CertBundle OPTIONAL, 
>>>>>    revInfos          [5] RevocationInfos OPTIONAL, 
>>>>>    queryExtensions   [6] Extensions OPTIONAL } 
>>>>
>>>>
>>>>In this structure trustAnchors was more or less an alternative to
>>>>valPolicy.
>>>>
>>>>In fact, IF the valPolicy is the default policy, THEN additional
>>>>parameters 
>>>>MUST be provided. So the structure below does not fit as well.
>>>>
>>>>This leads to have the two following elements:
>>>>
>>>>   valPolicy               ValidationPolicy,
>>>>   paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
>>>>
>>>>where the first one is mandatory and the second one optional.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>to  
>>>>>
>>>>> Query ::= SEQUENCE { 
>>>>>   queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>>
>>>>
>>>>>   checks                  CertChecks, 
>>>>>   wantBack                WantBack, 
>>>>>   requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>>   includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>>   inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>>   requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>>   ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>>   valAlgorithm            ValidationAlgorithm, 
>>>>>   serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>>   validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>>   trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>>   intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>>   revInfos            [4] RevocationInfos OPTIONAL, 
>>>>>   queryExtensions     [5] Extensions OPTIONAL } 
>>>>
>>>>
>>>>I would thus propose to have something like:
>>>>
>>>>Query ::= SEQUENCE {
>>>>       queriedCerts            SEQUENCE SIZE (1..MAX) OF
>>>>CertReference,
>>>>       checks                  CertChecks,
>>>>       wantBack                WantBack,
>>>>       requestRefHash          BOOLEAN DEFAULT TRUE,
>>>>       serverContextInfo       OCTET STRING OPTIONAL,
>>>>       validityTime            GeneralizedTime OPTIONAL,
>>>>       includePolResponse      BOOLEAN DEFAULT FALSE,
>>>>       valPolicy               ValidationPolicy,
>>>>       paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>>>>       intermediateCerts   [1] CertBundle OPTIONAL,
>>>>       revInfos            [2] RevocationInfos OPTIONAL,
>>>>       queryExtensions     [3] Extensions OPTIONAL }
>>>>
>>>>and then something like:
>>>>
>>>>  ParamsDefValPolicy :: = SEQUENCE {
>>>>      trustAnchors                  TrustAnchors,
>>>>      endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
>>>>OPTIONAL,
>>>>      inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>>>>      caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
>>>>OPTIONAL }
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I am not sure whether I am the only person unable to construct a
>>>>
>>>>parser.
>>>>
>>>>
>>>>
>>>>
>>>>>in version 14 an aditional flag has been added which is not
>>>>
> available
> 
>>>>in the
>>>>
>>>>
>>>>
>>>>
>>>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
>>>>
>>validation
>>
>>
>>>>>algorithms, or just to some of them, e.g,. the default name matching
>>>>
>>>>one? 
>>>>
>>>>
>>>>
>>>>
>>>>> Query ::= SEQUENCE { 
>>>>>   queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>>
>>>>
>>>>>   checks                  CertChecks, 
>>>>>   wantBack                WantBack, 
>>>>>   requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>>   includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>>   inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>>   requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>>   ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>>   isCA                    BOOLEAN DEFAULT FALSE, 
>>>>>   valAlgorithm            ValidationAlgorithm, 
>>>>>   serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>>   validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>>   trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>>   intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>>   revInfos            [4] RevocationInfos OPTIONAL, 
>>>>>   keyUsage            [5] KeyUsage OPTIONAL, 
>>>>>   extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>>>>   queryExtensions     [7] Extensions OPTIONAL  
>>>>>   producedAt          [8] GeneralizedTime OPTIONAL} 
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
> 
> 
> 

Date: Thu, 06 May 2004 10:35:08 -0400
From: Steve Hanna <[email-masked]>
Subject: Re: RFC 3280 bug in name constraints
To: Stefan Santesson <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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

I agree. In fact, I don't see why you wouldn't
apply name constraints to an EmailAddress attribute
in a subject DN even if there *is* an rfc822Name
in a subject alternative name. I suggest that
the text be revised to say:

    An rfc822 name constraint MUST be applied to an
    attribute of type EmailAddress in the subject
    distinguished name.

However, I'm willing to back down on this if
people feel it's too strict. My concern is that
a certificate with an email address in the
subject DN prohibited by name constraints will
be allowed because it also contains a permissible
email address in the subject alternative name.
I suspect many applications will not understand
this and will accept the email address in the
subject DN. In fact, RFC 2632 and its successor
don't contain any warning about this.

Thanks,

Steve

Stefan Santesson wrote:
> If someone is keeping record of bugs for future update of RFC 3280 I 
> have a small one to file about name constraints.
> 
>  
> 
> In section 4.2.1.11, starting at bottom of page 38:
> 
>  
> 
>    When rfc822 names are constrained, but the
> 
>    certificate does not include a subject alternative name, the rfc822
> 
>    name constraint MUST be applied to the attribute of type EmailAddress
> 
>    in the subject distinguished name.
> 
>  
> 
> Suppose/suggest that the intended meaning is:
> 
>  
> 
>    When rfc822 names are constrained, but the certificate does not
> 
>    include an rfc822Name in a subject alternative name extension, the rfc822
> 
>    name constraint MUST be applied to the attribute of type EmailAddress
> 
>    in the subject distinguished name.
> 
>  
> 
>  
> 
> Rationale:
> 
> Why would the constraint NOT apply to EmailAddress just because there is 
> a SubjAltName extension with e.g. just some unrelated other name 
> component present?
> 
>  
> 
> /Stefan
> 
>  
> 

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

--------------ms090804020804070103010908--

Date: Thu, 06 May 2004 10:25:15 -0400
From: Steve Hanna <[email-masked]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
To: Stefan Santesson <[email-masked]>
Cc: Wen-Cheng Wang <[email-masked]>, Stephen Kent <[email-masked]>, Santoni Adriano <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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

A better solution is to require (or at least recommend)
the ability to properly compare PrintableString and
UTF8String encodings. Paul Hoffman and I are working
on an Internet Draft describing how to do this (based
on the IDN and LDAP documents on the same topic).
This handles name constraints earlier in the path, etc.

Thanks,

Steve

Stefan Santesson wrote:
> Name rollover certificates only takes care of CA name changes.
> It doesn't solve the problem if subject names have mixed encoding in the
> forest of user certificates, while the CAs names are intact.
> 
> Neither does it solve when the constraint is placed above the CA
> rollover.
> 
> Finally, CA name rollover will most likely bust path validation using
> other constraining mechanisms because they may just not be recognized as
> self issued due to different name encoding. 
> 
> Stefan Santesson
> Program Manager, Windows Security
> 
> 
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Wen-Cheng Wang
>>Sent: den 5 maj 2004 23:40
>>To: Stefan Santesson; Stephen Kent; Santoni Adriano
>>Cc: [email-masked]; [email-masked]
>>Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
> 
> encoding
> 
>>RDNs
>>
>>
>>RFC 3280 does not ask CAs to replace all certificates at once for
>>migrating to UTF8String encoding. Instead, it suggest that
>>   "CAs MAY issue "name rollover" certificates to support an
>>     orderly migration to UTF8String encoding."
>>
>>I believe that if relying parties use 3280-compliant certification
> 
> path
> 
>>validation modules, then they will not have problem for processing
>>"name rollover" certificates, and thus the migration to UTF8String
>>encoding will not be a problem.
>>
>>One thing should be noted: a "name rollover" certificate is
> 
> essentially
> 
>>a "self-issued certificate" but its issuer name and subject name is in
>>different encoding. Therefore, the definition of "self-issued
> 
> certificate"
> 
>>should be changed a little. Also, since a "name rollover" certificate
> 
> may
> 
>>contains a NameConstraints extension in which the permittedSubtrees
>>and excludedSubtrees will be in a new encoding (e.g., UTF8String),
>>the path validation in RFC 3280 also need to be revised. I hope all of
>>these should be addressed in sonOfRfc3280.
>>
>>I don't think that RFC 3280 mandates the support for UTF8String
>>encoding is "at odds with reality". There are many countries/regions
>>in the world where it is impossible to encode names in Printable
> 
> String.
> 
>>In Taiwan, we have already millions of certificates with issuer names
>>and subject names encoded in UTF8String.
>>
>>Three years ago, I tested some VPN devices and found most of them
>>can not accept certificates with UTF8String (One of them even crashed
>>if received a certificate with UTF8String). Recently, I test many VPN
>>devices
>>again and amazingly found the all of them can normally handle
> 
> certificates
> 
>>with
>>UTF8String. All of them can chain and validate certificte paths that
>>contains
>>certificates with UTF8String. (Although, most of them still can not
>>display
>>the
>>UTF8String in Chinese correctly. It is a pity.)
>>
>>The truth is that there are more and more applications that can
> 
> handling
> 
>>UTF8String encoding. I think the credit should give to RFC 3280 for
> 
> its
> 
>>mandating  for UTF8String encoding.
>>
>>Wen-Cheng Wang
>>
>>
>>----- Original Message -----
>>From: "Stefan Santesson" <[email-masked]>
>>To: "Stephen Kent" <[email-masked]>; "Santoni Adriano"
>><[email-masked]>
>>Cc: <[email-masked]>; <[email-masked]>
>>Sent: Thursday, May 06, 2004 8:18 AM
>>Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in
> 
> encoding
> 
>>RDNs
>>
>>
>>
>>>
>>>Steve,
>>>
>>>There is one unfortunate side effect that makes this requirement
> 
> worse
> 
>>>than other evolutions of standards.
>>>
>>>It is almost never feasible to replace all certificates in a
> 
> hierarchy
> 
>>>at once. This means that you over time will have a mixed environment
>>>where e.g. the same organization name will exist in different
> 
> encoding
> 
>>>in many places of your hierarchy.
>>>
>>>It will then be virtually impossible to apply name constraining in
> 
> such
> 
>>>environment because RFC 3280 does not mandate the full X.500 name
>>>matching rules and a client may subsequently decide that names with
>>>different encoding is a no-match.
>>>
>>>This seams to be an unsolvable problem that, looking in the mirror,
> 
> is
> 
>>>inadequately addressed and shouldn't have passed in its current
> 
> form. In
> 
>>>fact it is probably a defect that needs to be addressed in
> 
> sonOfRfc3280
> 
>>>in one way or the other.
>>>
>>>/Stefan
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email-masked]
>>>
>>>[mailto:[email-masked]]
>>>
>>>>On Behalf Of Stephen Kent
>>>>Sent: den 5 maj 2004 13:36
>>>>To: Santoni Adriano
>>>>Cc: [email-masked]'; [email-masked]
>>>>Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
>>>
>>>encoding
>>>
>>>>RDNs
>>>>
>>>>
>>>>At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
>>>>
>>>>>A rule that is "at odds with reality" should not be expressed in
>>>
>>>terms of
>>>
>>>>>MUST, but rather in terms of SHOULD. I wonder how it came that
> 
> RFC
> 
>>>3280
>>>
>>>>>reached the status of an official IETF standard, if it contains
> 
> one
> 
>>>or
>>>
>>>>more
>>>>
>>>>>areas that are "at odds with reality".
>>>>>
>>>>>I suppose the answer is one of these:
>>>>>- RFC 3280 does not really contain areas that are "at odds with
>>>
>>>reality"
>>>
>>>>-
>>>>
>>>>>it's just that we do not understand them;
>>>>
>>>>RFC 3280 established a requirement for a change in how DNs are
>>>>encoded, for a future point in time. Thus, at the time the RFC was
>>>>published as a standard of course it did not match "reality."
> 
> since
> 
>>>>it was calling for a change.  By the way, this change was not the
>>>>idea of the PKIX WG but rather is consistent with the overall IETF
>>>>mandate to better accommodate character sets for a wide range of
>>>>languages.
>>>>
>>>>
>>>>>- containing areas that are "at odds with reality" is not an
> 
> obstacle
> 
>>>to
>>>
>>>>>becoming a standard;
>>>>
>>>>Think of the implication of your comment. if we were never able to
>>>>call for a change in how things are done when we update a
> 
> standard,
> 
>>>>then we could never make any changes.  obviously this would be
> 
> unduly
> 
>>>>limiting.
>>>>
>>>>
>>>>>- expressions like "MUST" in IETF standard are really to be taken
> 
> as
> 
>>>mere
>>>
>>>>>suggestions;
>>>>
>>>>IETF standards are voluntary. failure to comply is not punishable
> 
> :-)
> 
>>>>>- nobody really cares.
>>>>
>>>>one might say that in environments where a few vendors or service
>>>>providers control a significant market share, their deviation from
>>>>standards, or failure to accommodate changes in standards, can
> 
> have
> 
>>>>profound impacts.
>>>>
>>>>Steve
>>>
>>>
> 
> 

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

--------------ms020005020303050707030801--

Content-class: urn:content-classes:message
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Thu, 6 May 2004 14:32:41 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Santoni Adriano" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Name rollover certificates only takes care of CA name changes.
It doesn't solve the problem if subject names have mixed encoding in the
forest of user certificates, while the CAs names are intact.

Neither does it solve when the constraint is placed above the CA
rollover.

Finally, CA name rollover will most likely bust path validation using
other constraining mechanisms because they may just not be recognized as
self issued due to different name encoding. 

Stefan Santesson
Program Manager, Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Wen-Cheng Wang
> Sent: den 5 maj 2004 23:40
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [email-masked]; [email-masked]
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> RFC 3280 does not ask CAs to replace all certificates at once for
> migrating to UTF8String encoding. Instead, it suggest that
>    "CAs MAY issue "name rollover" certificates to support an
>      orderly migration to UTF8String encoding."
> 
> I believe that if relying parties use 3280-compliant certification
path
> validation modules, then they will not have problem for processing
> "name rollover" certificates, and thus the migration to UTF8String
> encoding will not be a problem.
> 
> One thing should be noted: a "name rollover" certificate is
essentially
> a "self-issued certificate" but its issuer name and subject name is in
> different encoding. Therefore, the definition of "self-issued
certificate"
> should be changed a little. Also, since a "name rollover" certificate
may
> contains a NameConstraints extension in which the permittedSubtrees
> and excludedSubtrees will be in a new encoding (e.g., UTF8String),
> the path validation in RFC 3280 also need to be revised. I hope all of
> these should be addressed in sonOfRfc3280.
> 
> I don't think that RFC 3280 mandates the support for UTF8String
> encoding is "at odds with reality". There are many countries/regions
> in the world where it is impossible to encode names in Printable
String.
> In Taiwan, we have already millions of certificates with issuer names
> and subject names encoded in UTF8String.
> 
> Three years ago, I tested some VPN devices and found most of them
> can not accept certificates with UTF8String (One of them even crashed
> if received a certificate with UTF8String). Recently, I test many VPN
> devices
> again and amazingly found the all of them can normally handle
certificates
> with
> UTF8String. All of them can chain and validate certificte paths that
> contains
> certificates with UTF8String. (Although, most of them still can not
> display
> the
> UTF8String in Chinese correctly. It is a pity.)
> 
> The truth is that there are more and more applications that can
handling
> UTF8String encoding. I think the credit should give to RFC 3280 for
its
> mandating  for UTF8String encoding.
> 
> Wen-Cheng Wang
> 
> 
> ----- Original Message -----
> From: "Stefan Santesson" <[email-masked]>
> To: "Stephen Kent" <[email-masked]>; "Santoni Adriano"
> <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, May 06, 2004 8:18 AM
> Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> >
> >
> > Steve,
> >
> > There is one unfortunate side effect that makes this requirement
worse
> > than other evolutions of standards.
> >
> > It is almost never feasible to replace all certificates in a
hierarchy
> > at once. This means that you over time will have a mixed environment
> > where e.g. the same organization name will exist in different
encoding
> > in many places of your hierarchy.
> >
> > It will then be virtually impossible to apply name constraining in
such
> > environment because RFC 3280 does not mandate the full X.500 name
> > matching rules and a client may subsequently decide that names with
> > different encoding is a no-match.
> >
> > This seams to be an unsolvable problem that, looking in the mirror,
is
> > inadequately addressed and shouldn't have passed in its current
form. In
> > fact it is probably a defect that needs to be addressed in
sonOfRfc3280
> > in one way or the other.
> >
> > /Stefan
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Stephen Kent
> > > Sent: den 5 maj 2004 13:36
> > > To: Santoni Adriano
> > > Cc: [email-masked]'; [email-masked]
> > > Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
> > encoding
> > > RDNs
> > >
> > >
> > > At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
> > > >A rule that is "at odds with reality" should not be expressed in
> > terms of
> > > >MUST, but rather in terms of SHOULD. I wonder how it came that
RFC
> > 3280
> > > >reached the status of an official IETF standard, if it contains
one
> > or
> > > more
> > > >areas that are "at odds with reality".
> > > >
> > > >I suppose the answer is one of these:
> > > >- RFC 3280 does not really contain areas that are "at odds with
> > reality"
> > > -
> > > >it's just that we do not understand them;
> > >
> > > RFC 3280 established a requirement for a change in how DNs are
> > > encoded, for a future point in time. Thus, at the time the RFC was
> > > published as a standard of course it did not match "reality."
since
> > > it was calling for a change.  By the way, this change was not the
> > > idea of the PKIX WG but rather is consistent with the overall IETF
> > > mandate to better accommodate character sets for a wide range of
> > > languages.
> > >
> > > >- containing areas that are "at odds with reality" is not an
obstacle
> > to
> > > >becoming a standard;
> > >
> > > Think of the implication of your comment. if we were never able to
> > > call for a change in how things are done when we update a
standard,
> > > then we could never make any changes.  obviously this would be
unduly
> > > limiting.
> > >
> > > >- expressions like "MUST" in IETF standard are really to be taken
as
> > mere
> > > >suggestions;
> > >
> > > IETF standards are voluntary. failure to comply is not punishable
:-)
> > >
> > > >- nobody really cares.
> > >
> > > one might say that in environments where a few vendors or service
> > > providers control a significant market share, their deviation from
> > > standards, or failure to accommodate changes in standards, can
have
> > > profound impacts.
> > > Steve

From: "Wen-Cheng Wang" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: FW: scvp
Date: Thu, 6 May 2004 18:35:54 +0800
Sender: [email-masked]

I don't agree that the broader consensus is for a "al a carte".
(Maybe we should have a straw poll to decide what is the 
broader consensus?)

When designing a DPV protocol, please do not forget that the
two main benefits to establish a DPV server are:

1. it reduces the burden for application implementators to implement
    certification path processing modules by themself;
2. it allows validation against management-defined validation policies
    in a consistent fashion across an application domain (e.g., an
    enterprise).

I believe that application implementors do not want "al a carte"
combinations, they will prefer suits instead. If a DPV server requires
application implementors to use a DPV client API that needs
the implementors to specify a validation policy OID with many initial
mystery parameters, then what is the benefit to use the DPV server?
Why not simply use a certification path processing API such as CML
instead a DPV client API if the burden is the same? At least, you can
save the budget for establishing a DPV server if you choose to use
CML.

Besides, in an application domain where the authority wish
to force all applications to validate certification path against
management-defined validation policies in a consistent fashion,
the applications will not even be allowed to specify any initial
parameters (except the certificate to be validated). If the client
side is allows to specfy its own initial parameters, how can the
validation be guaranteed to proceed in the consistent fashion?
In an application domain with a centralized validation policy, the
server side will decide almost all the initial parameters according
to the validation policy. In such case, the client side need not
(and might not be allowed) to specify any initial parameters
(except the certificate to be validated, of course).

I believe that in most use cases of DPV, the client side will need
not to specify any initial parameters. Therefore, why not simplify the
syntax of the SCVP so that the client side do not to specify any initial
parameters in a basic request. In my opinion, the SCVP is not a
"simple" protocol anymore. Let's simplify it so that it deserve the
name of a "simple" protocol.

That is not to say that the SCVP can not provide a mechanism
for the client side to specify its own validation policy and initial
parameters if the server side allows its clients to do that, but this
can be achieved by using the "Extension" mechanism. In the most
case, there is no need  for the client side to specify its own validation
policy and initial parameters, so please do not let the basic syntax
so complicated.

Personally, I think the draft 12 syntax is better than draft 13/14.
Maybe we should go back to the draft 12 syntax and try to define
some extensions based on that syntax.

Wen-Cheng Wang

----- Original Message ----- 
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 05, 2004 1:22 AM
Subject: RE: FW: scvp

> 
> Hi Denis,
> There is no mandate in 3379 that a validation policy must be expressed
> with a single value. It is not clear that is any value is doing so since
> it only raised more ambiguity. This is well trod turf by many groups who
> have debated the merits of providing suits vs. "al a carte" combinations
> of inputs and the broader consensus is for a "al a carte".
> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Tuesday, May 04, 2004 3:15 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> > Hi Denis,
> > 
> > 3379 does not require that the validation policy be specified in a
> > single value. 
> 
> You are playing with words. The text says:
> "most clients will simply reference a validation policy"
> 
> This means that validation policies can be referenced and thus
> parameters do 
> not need to be defined through this interface.
> 
> A simple and good reference is an OID.
> 
> > With SCVP14 a client can accept the default of the SCVP
> > server or specify a set of parameters which constitutes its validation
> > policy. That is consistent with the requirements of 3379.
> 
> The specification of the set of parameters should be done through a 
> different interface. This different interface can then return an OID 
> Whatever this additional interface can be, it will never be rich enough
> to 
> pass all the details of the validation policy. Thus OIDs can also be
> defined 
> not using this additional interface.
> 
> Denis
> 
> > Trevor
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]] 
> > Sent: Thursday, April 29, 2004 3:54 AM
> > To: Trevor Freeman
> > Cc: [email-masked]
> > Subject: Re: FW: scvp
> > 
> > Trevor,
> > 
> > 
> >>Hi Denis,
> > 
> > 
> >>Can you please be more specific how you think SCVP 14 does not comply
> >>with 3379.
> >>
> >>I can find no section in 3379 where is there a requirement that a
> >>validation policy MUST be represented as an OID. 
> > 
> > 
> > There cannot be a requirement with such a level of detail, but the
> text
> > states:
> > 
> >     The protocol MUST allow the client to include
> >     these policy dependant parameters in the DPV request; however, it
> is
> >     expected that most clients will simply reference a validation
> policy
> >     for a given application or accept the DPV server's default
> > validation
> >     policy.
> > 
> > A simple reference is an OID.
> > 
> > FYI, I do not expect to use the "default validation policy".
> > 
> > Denis
> > 
> > 
> > 
> >>Given hiding the detail of what a policy is within an OID simply opens
> >>the rat hole of what change to the policy constitutes a change to the
> >>OID, it is less ambiguous to refer to the primary data. Once you are
> > 
> > in
> > 
> >>the business of managing state on a client, then there is negligible
> >>cost increase incurred in managing several data points vs. a singe
> > 
> > data
> > 
> >>point.
> >>
> >>Trevor
> >>
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[email-masked]] 
> >>Sent: Tuesday, April 27, 2004 11:01 AM
> >>To: Trevor Freeman
> >>Cc: [email-masked]
> >>Subject: Re: FW: scvp
> >>
> >>Trevor,
> >>
> >>
> >>
> >>>HI Denis,
> >>>In SCVP13, the concept of validation policy was not completely in
> >>>alignment  with 3379 definition. 
> >>
> >>
> >>Well, it is different and this is a major problem.
> >>
> >>
> >>
> >>>It also blurred the distinction between
> >>>validation policy and validation algorithm. 
> >>
> >>
> >>This is also a majo problem.
> >>
> >>
> >>
> >>>Therefore I have defined
> >>>what each is in SCVP 14 and aligned the structures accordingly.
> >>>Section 1.3 has the following.
> >>>"In SCVP, the validation policy comprises of an algorithm for
> >>>certificate path processing and the input parameters to the
> >>
> >>algorithm."
> >>
> >>This does not comply with RFC 3379.
> >>
> >>
> >>
> >>>Therefore trust anchors are an input into the algorithm  and
> therefore
> >>>separate.
> >>
> >>
> >>Therefore I do not follow you.
> >>
> >> From an interface point of view the simplest validation policy is
> >>defined 
> >>by an OID where all the parameters necessary to perform the validation
> >>check 
> >>are "behind" the OID. There is no need to provide any parameter
> > 
> > through
> > 
> >>the 
> >>interface.
> >>
> >>When there are some parameters, then they are specific to the
> > 
> > validation
> > 
> >>policy. I have no problem to provide specific parameters for what is
> >>called 
> >>the "default validation policy" which is only a particular validation
> >>policy 
> >>among many others.
> >>
> >>Simple clients will be unable to pass any parameter but will know
> > 
> > which
> > 
> >>OIDs 
> >>(for the validation policy) are appropriate for their applications.
> >>
> >>Denis
> >>
> >>
> >>
> >>>This is in alignment with 3379s definition of validation policy.
> >>>
> >>>Trevor
> >>>
> >>>-----Original Message-----
> >>>From: Denis Pinkas [mailto:[email-masked]] 
> >>>Sent: Monday, April 26, 2004 1:09 AM
> >>>To: Peter Sylvester
> >>>Cc: [email-masked]; Trevor Freeman
> >>>Subject: Re: FW: scvp
> >>>
> >>>Peter and Trevor,
> >>>
> >>>I have major problems too.
> >>>
> >>>
> >>>
> >>>
> >>>>in version 13 the syntax for a Query has been changed from
> >>>>
> >>>> Query ::= SEQUENCE { 
> >>>>     queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
> >>>>     checks                CertChecks, 
> >>>>     wantBack              WantBack, 
> >>>>     serverContextInfo [0] OCTET STRING OPTIONAL, 
> >>>>     valPolicy         [1] ValidationPolicy OPTIONAL, 
> >>>>     validityTime      [2] GeneralizedTime OPTIONAL, 
> >>>>     trustAnchors      [3] TrustAnchors OPTIONAL, 
> >>>>     intermediateCerts [4] CertBundle OPTIONAL, 
> >>>>     revInfos          [5] RevocationInfos OPTIONAL, 
> >>>>     queryExtensions   [6] Extensions OPTIONAL } 
> >>>
> >>>
> >>>In this structure trustAnchors was more or less an alternative to
> >>>valPolicy.
> >>>
> >>>In fact, IF the valPolicy is the default policy, THEN additional
> >>>parameters 
> >>>MUST be provided. So the structure below does not fit as well.
> >>>
> >>>This leads to have the two following elements:
> >>>
> >>>    valPolicy               ValidationPolicy,
> >>>    paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
> >>>
> >>>where the first one is mandatory and the second one optional.
> >>>
> >>>
> >>>
> >>>
> >>>>to  
> >>>>
> >>>>  Query ::= SEQUENCE { 
> >>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
> >>>
> >>>
> >>>>    checks                  CertChecks, 
> >>>>    wantBack                WantBack, 
> >>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
> >>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
> >>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
> >>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
> >>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
> >>>>    valAlgorithm            ValidationAlgorithm, 
> >>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
> >>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
> >>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
> >>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
> >>>>    revInfos            [4] RevocationInfos OPTIONAL, 
> >>>>    queryExtensions     [5] Extensions OPTIONAL } 
> >>>
> >>>
> >>>I would thus propose to have something like:
> >>>
> >>>Query ::= SEQUENCE {
> >>>        queriedCerts            SEQUENCE SIZE (1..MAX) OF
> >>>CertReference,
> >>>        checks                  CertChecks,
> >>>        wantBack                WantBack,
> >>>        requestRefHash          BOOLEAN DEFAULT TRUE,
> >>>        serverContextInfo       OCTET STRING OPTIONAL,
> >>>        validityTime            GeneralizedTime OPTIONAL,
> >>>        includePolResponse      BOOLEAN DEFAULT FALSE,
> >>>        valPolicy               ValidationPolicy,
> >>>        paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
> >>>        intermediateCerts   [1] CertBundle OPTIONAL,
> >>>        revInfos            [2] RevocationInfos OPTIONAL,
> >>>        queryExtensions     [3] Extensions OPTIONAL }
> >>>
> >>>and then something like:
> >>>
> >>>   ParamsDefValPolicy :: = SEQUENCE {
> >>>       trustAnchors                  TrustAnchors,
> >>>       endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
> >>>OPTIONAL,
> >>>       inhibitPolMap                 BOOLEAN DEFAULT FALSE,
> >>>       caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
> >>>OPTIONAL }
> >>>
> >>>Denis
> >>>
> >>>
> >>>
> >>>
> >>>>I am not sure whether I am the only person unable to construct a
> >>>
> >>>parser.
> >>>
> >>>
> >>>
> >>>>in version 14 an aditional flag has been added which is not
> available
> >>>
> >>>in the
> >>>
> >>>
> >>>
> >>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
> >>>
> > validation
> > 
> >>>>algorithms, or just to some of them, e.g,. the default name matching
> >>>
> >>>one? 
> >>>
> >>>
> >>>
> >>>>  Query ::= SEQUENCE { 
> >>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
> >>>
> >>>
> >>>>    checks                  CertChecks, 
> >>>>    wantBack                WantBack, 
> >>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
> >>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
> >>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
> >>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
> >>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
> >>>>    isCA                    BOOLEAN DEFAULT FALSE, 
> >>>>    valAlgorithm            ValidationAlgorithm, 
> >>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
> >>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
> >>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
> >>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
> >>>>    revInfos            [4] RevocationInfos OPTIONAL, 
> >>>>    keyUsage            [5] KeyUsage OPTIONAL, 
> >>>>    extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
> >>>>    queryExtensions     [7] Extensions OPTIONAL  
> >>>>    producedAt          [8] GeneralizedTime OPTIONAL} 
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> > 
> > 
> > 
> 
> 
> 

From: Santoni Adriano <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Stephen Kent <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: R: R: I: R: RFC3280: doubt on the use of UTF8String in encoding R DNs
Date: Thu, 6 May 2004 08:42:31 +0200 
Sender: [email-masked]

Thanks to both Kent and Santesson for their comments.

Of course, it was not my intention to argument against the adoption of
UTF8String. On the contrary, I am personally convinced that is (would be?
will be?) a good and sensible initiative.

And of course, my previous message was provocative, as I am perfectly aware
that "if we were never able to call for a change in how things are done when
we update a standard, then we could never make any changes", and that "IETF
standards are voluntary. failure to comply is not punishable"; I dare to say
that is quite obvious to almost anyone in the industry.

Actually, it is not just the compliance to IETF standards which is
voluntary. It is also the degree of compliance and the very meaning of
compliance, to be voluntary. It is just too easy to claim compliance to any
standard. What if RFCs had an incipit saying something like <<Failure to
comply to any of the mandatory features herein described shall be equivalent
to not being compliant at all with this standard. It is prohibited to claim
compliance with this standard unless each and all of the mandatory features
herein described are fully obeyed to>>. Well, I know I am being too candid
with this idea...

However, it would be nice to see a meaningful number of CAs discuss this
topic and try to decide on the way to go. Should we try to switch to
UTF8String during the current year? Or in the next year? Or just leave any
CA do what it likes, regardless of any "MUST" or deadlines that happen to
show up in RFCs? This mailing list should be the right place to discuss
that, but it seems the topic is not very interesting...

Adriano

-----Messaggio originale-----
Da: Stefan Santesson [mailto:[email-masked]] 
Inviato: giovedì 6 maggio 2004 2.18
A: Stephen Kent; Santoni Adriano
Cc: [email-masked]; [email-masked]
Oggetto: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs

Steve,

There is one unfortunate side effect that makes this requirement worse than
other evolutions of standards.

It is almost never feasible to replace all certificates in a hierarchy at
once. This means that you over time will have a mixed environment where e.g.
the same organization name will exist in different encoding in many places
of your hierarchy.

It will then be virtually impossible to apply name constraining in such
environment because RFC 3280 does not mandate the full X.500 name matching
rules and a client may subsequently decide that names with different
encoding is a no-match.

This seams to be an unsolvable problem that, looking in the mirror, is
inadequately addressed and shouldn't have passed in its current form. In
fact it is probably a defect that needs to be addressed in sonOfRfc3280 in
one way or the other.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 5 maj 2004 13:36
> To: Santoni Adriano
> Cc: [email-masked]'; [email-masked]
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
> >A rule that is "at odds with reality" should not be expressed in
terms of
> >MUST, but rather in terms of SHOULD. I wonder how it came that RFC
3280
> >reached the status of an official IETF standard, if it contains one
or
> more
> >areas that are "at odds with reality".
> >
> >I suppose the answer is one of these:
> >- RFC 3280 does not really contain areas that are "at odds with
reality"
> -
> >it's just that we do not understand them;
> 
> RFC 3280 established a requirement for a change in how DNs are 
> encoded, for a future point in time. Thus, at the time the RFC was 
> published as a standard of course it did not match "reality." since it 
> was calling for a change.  By the way, this change was not the idea of 
> the PKIX WG but rather is consistent with the overall IETF mandate to 
> better accommodate character sets for a wide range of languages.
> 
> >- containing areas that are "at odds with reality" is not an obstacle
to
> >becoming a standard;
> 
> Think of the implication of your comment. if we were never able to 
> call for a change in how things are done when we update a standard, 
> then we could never make any changes.  obviously this would be unduly 
> limiting.
> 
> >- expressions like "MUST" in IETF standard are really to be taken as
mere
> >suggestions;
> 
> IETF standards are voluntary. failure to comply is not punishable :-)
> 
> >- nobody really cares.
> 
> one might say that in environments where a few vendors or service 
> providers control a significant market share, their deviation from 
> standards, or failure to accommodate changes in standards, can have 
> profound impacts.
> 
> Steve

*******************Internet Email Confidentiality Footer******************* 
Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi
allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto
erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne
comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso
e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente
messaggio nonche' nei suoi eventuali allegati devono essere attribuite
esclusivamente al mittente e non possono essere considerate come trasmesse o
autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA
S.p.A. nei confronti del destinatario o di terzi. 
SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of SIA. Besides, The contents
of this message shall be understood as neither given nor endorsed by SIA
S.p.A.. 
SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof. 

From: "Wen-Cheng Wang" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Santoni Adriano" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Thu, 6 May 2004 14:39:51 +0800
Sender: [email-masked]

RFC 3280 does not ask CAs to replace all certificates at once for
migrating to UTF8String encoding. Instead, it suggest that
   "CAs MAY issue "name rollover" certificates to support an
     orderly migration to UTF8String encoding."

I believe that if relying parties use 3280-compliant certification path
validation modules, then they will not have problem for processing
"name rollover" certificates, and thus the migration to UTF8String
encoding will not be a problem.

One thing should be noted: a "name rollover" certificate is essentially
a "self-issued certificate" but its issuer name and subject name is in
different encoding. Therefore, the definition of "self-issued certificate"
should be changed a little. Also, since a "name rollover" certificate may
contains a NameConstraints extension in which the permittedSubtrees
and excludedSubtrees will be in a new encoding (e.g., UTF8String),
the path validation in RFC 3280 also need to be revised. I hope all of
these should be addressed in sonOfRfc3280.

I don't think that RFC 3280 mandates the support for UTF8String
encoding is "at odds with reality". There are many countries/regions
in the world where it is impossible to encode names in Printable String.
In Taiwan, we have already millions of certificates with issuer names
and subject names encoded in UTF8String.

Three years ago, I tested some VPN devices and found most of them
can not accept certificates with UTF8String (One of them even crashed
if received a certificate with UTF8String). Recently, I test many VPN
devices
again and amazingly found the all of them can normally handle certificates
with
UTF8String. All of them can chain and validate certificte paths that
contains
certificates with UTF8String. (Although, most of them still can not display
the
UTF8String in Chinese correctly. It is a pity.)

The truth is that there are more and more applications that can handling
UTF8String encoding. I think the credit should give to RFC 3280 for its
mandating  for UTF8String encoding.

Wen-Cheng Wang

----- Original Message ----- 
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>; "Santoni Adriano"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, May 06, 2004 8:18 AM
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs

>
>
> Steve,
>
> There is one unfortunate side effect that makes this requirement worse
> than other evolutions of standards.
>
> It is almost never feasible to replace all certificates in a hierarchy
> at once. This means that you over time will have a mixed environment
> where e.g. the same organization name will exist in different encoding
> in many places of your hierarchy.
>
> It will then be virtually impossible to apply name constraining in such
> environment because RFC 3280 does not mandate the full X.500 name
> matching rules and a client may subsequently decide that names with
> different encoding is a no-match.
>
> This seams to be an unsolvable problem that, looking in the mirror, is
> inadequately addressed and shouldn't have passed in its current form. In
> fact it is probably a defect that needs to be addressed in sonOfRfc3280
> in one way or the other.
>
> /Stefan
>
>
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Stephen Kent
> > Sent: den 5 maj 2004 13:36
> > To: Santoni Adriano
> > Cc: [email-masked]'; [email-masked]
> > Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
> encoding
> > RDNs
> >
> >
> > At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
> > >A rule that is "at odds with reality" should not be expressed in
> terms of
> > >MUST, but rather in terms of SHOULD. I wonder how it came that RFC
> 3280
> > >reached the status of an official IETF standard, if it contains one
> or
> > more
> > >areas that are "at odds with reality".
> > >
> > >I suppose the answer is one of these:
> > >- RFC 3280 does not really contain areas that are "at odds with
> reality"
> > -
> > >it's just that we do not understand them;
> >
> > RFC 3280 established a requirement for a change in how DNs are
> > encoded, for a future point in time. Thus, at the time the RFC was
> > published as a standard of course it did not match "reality." since
> > it was calling for a change.  By the way, this change was not the
> > idea of the PKIX WG but rather is consistent with the overall IETF
> > mandate to better accommodate character sets for a wide range of
> > languages.
> >
> > >- containing areas that are "at odds with reality" is not an obstacle
> to
> > >becoming a standard;
> >
> > Think of the implication of your comment. if we were never able to
> > call for a change in how things are done when we update a standard,
> > then we could never make any changes.  obviously this would be unduly
> > limiting.
> >
> > >- expressions like "MUST" in IETF standard are really to be taken as
> mere
> > >suggestions;
> >
> > IETF standards are voluntary. failure to comply is not punishable :-)
> >
> > >- nobody really cares.
> >
> > one might say that in environments where a few vendors or service
> > providers control a significant market share, their deviation from
> > standards, or failure to accommodate changes in standards, can have
> > profound impacts.
> >
> > Steve
>
>

Content-class: urn:content-classes:message
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Thu, 6 May 2004 01:18:25 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Santoni Adriano" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Steve,

There is one unfortunate side effect that makes this requirement worse
than other evolutions of standards.

It is almost never feasible to replace all certificates in a hierarchy
at once. This means that you over time will have a mixed environment
where e.g. the same organization name will exist in different encoding
in many places of your hierarchy.

It will then be virtually impossible to apply name constraining in such
environment because RFC 3280 does not mandate the full X.500 name
matching rules and a client may subsequently decide that names with
different encoding is a no-match.

This seams to be an unsolvable problem that, looking in the mirror, is
inadequately addressed and shouldn't have passed in its current form. In
fact it is probably a defect that needs to be addressed in sonOfRfc3280
in one way or the other.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 5 maj 2004 13:36
> To: Santoni Adriano
> Cc: [email-masked]'; [email-masked]
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
> >A rule that is "at odds with reality" should not be expressed in
terms of
> >MUST, but rather in terms of SHOULD. I wonder how it came that RFC
3280
> >reached the status of an official IETF standard, if it contains one
or
> more
> >areas that are "at odds with reality".
> >
> >I suppose the answer is one of these:
> >- RFC 3280 does not really contain areas that are "at odds with
reality"
> -
> >it's just that we do not understand them;
> 
> RFC 3280 established a requirement for a change in how DNs are
> encoded, for a future point in time. Thus, at the time the RFC was
> published as a standard of course it did not match "reality." since
> it was calling for a change.  By the way, this change was not the
> idea of the PKIX WG but rather is consistent with the overall IETF
> mandate to better accommodate character sets for a wide range of
> languages.
> 
> >- containing areas that are "at odds with reality" is not an obstacle
to
> >becoming a standard;
> 
> Think of the implication of your comment. if we were never able to
> call for a change in how things are done when we update a standard,
> then we could never make any changes.  obviously this would be unduly
> limiting.
> 
> >- expressions like "MUST" in IETF standard are really to be taken as
mere
> >suggestions;
> 
> IETF standards are voluntary. failure to comply is not punishable :-)
> 
> >- nobody really cares.
> 
> one might say that in environments where a few vendors or service
> providers control a significant market share, their deviation from
> standards, or failure to accommodate changes in standards, can have
> profound impacts.
> 
> Steve

Date: Wed, 5 May 2004 16:36:24 -0400
To: Santoni Adriano <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
>A rule that is "at odds with reality" should not be expressed in terms of
>MUST, but rather in terms of SHOULD. I wonder how it came that RFC 3280
>reached the status of an official IETF standard, if it contains one or more
>areas that are "at odds with reality".
>
>I suppose the answer is one of these:
>- RFC 3280 does not really contain areas that are "at odds with reality" -
>it's just that we do not understand them;

RFC 3280 established a requirement for a change in how DNs are 
encoded, for a future point in time. Thus, at the time the RFC was 
published as a standard of course it did not match "reality." since 
it was calling for a change.  By the way, this change was not the 
idea of the PKIX WG but rather is consistent with the overall IETF 
mandate to better accommodate character sets for a wide range of 
languages.

>- containing areas that are "at odds with reality" is not an obstacle to
>becoming a standard;

Think of the implication of your comment. if we were never able to 
call for a change in how things are done when we update a standard, 
then we could never make any changes.  obviously this would be unduly 
limiting.

>- expressions like "MUST" in IETF standard are really to be taken as mere
>suggestions;

IETF standards are voluntary. failure to comply is not punishable :-)

>- nobody really cares.

one might say that in environments where a few vendors or service 
providers control a significant market share, their deviation from 
standards, or failure to accommodate changes in standards, can have 
profound impacts.

Steve

Date: Wed, 05 May 2004 17:26:00 -0400
From: Steve Hanna <[email-masked]>
Subject: Re: Cross certificate format
To: Tom Gindin <[email-masked]>
Cc: Santosh Chokhani <[email-masked]>, [email-masked]
Sender: [email-masked]

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

See section 6.2 of RFC 3280, which says:

    ...  An implementation that supports multiple trust anchors
    MAY augment the algorithm presented in section 6.1 to further limit
    the set of valid certification paths which begin with a particular
    trust anchor.  For example, an implementation MAY modify the
    algorithm to apply name constraints to a specific trust anchor during
    the initialization phase, or the application MAY require the presence
    of a particular alternative name form in the end entity certificate,
    or the application MAY impose requirements on application-specific
    extensions.  Thus, the path validation algorithm presented in section
    6.1 defines the minimum conditions for a path to be considered valid.

There's no need to change RFC 3280 to allow
path validation implementations to apply
name constraints to trust anchors. That's
explicitly discussed in this section of the RFC.

Thanks,

Steve

Tom Gindin wrote:
>         Santosh:
> 
>         Of course, defining a trust anchor implies that the RP trusts the 
> anchor's public key as an issuer for at least some purposes.  RFC 3280, in 
> the parts of section 6.1.2 I cited, appears to forbid those state 
> variables from being set from information defined by the RP or stored with 
> the trust anchor.  This is consistent with its statements in 6.1.1 d which 
> permit self-signed certificates but say nothing about other CA 
> certificates.  As is probably clear to everyone reading this thread, I 
> think that this is not an ideal set of suggestions.
>         The current standard does contain some constraints on the trust 
> anchor (notably inhibit-policy-mapping), but neither name constraints nor 
> basic constraints.  I consider this an anomaly.  If I had free rein in 
> rewording pieces of RFC 3280 section 6.1, I would change this wording to 
> allow CA certificates along with self-signed ones as anchors and create 
> extra optional (and optional to support) fields to be set from the trust 
> anchor.
>         I don't think that this is particularly inconsistent with general 
> security principles, or with any part of X.509 with which I am familiar. 
> It does represent an extension of RFC 3280 section 6, and it is only 
> backward compatible with it, so it may be out of scope.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> Sent by: [email-masked]
> 05/01/2004 06:46 PM
> 
>  
>         To:     <[email-masked]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> The standard does not require you to check how you initialize the 
> variables.
> You can get these from the cross certificate or from some configuration.
> 
> The basic point is that you trust the public key.  How you constrain it is
> not address by the standard, where as if the same certificate appeared in 
> a
> path, you have to apply the constraints or be not compliant with the
> standard.
> 
> You obviously do not believe in re-incarnation.  Just kidding......
> 
> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]] 
> Sent: Saturday, May 01, 2004 6:31 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: RE: Cross certificate format
> 
> 
>         Santosh:
> 
>         It is well known that trust in a trust anchor can be defined in a 
> variety of ways.  However, there is every reason to think that an RP may 
> constrain that trust and that the constraints he may apply include those 
> which an issuer CA may apply to a subordinate one. The wording of RFC 3280 
> 
> section 6.2's first paragraph is an example of this.
>         My comments about the meaning of a trust anchor are not purely 
> theoretical.  If a cross certificate is used to represent a trust anchor, 
> the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
> (RFC 3280 6.1.2 c) could easily be set from the contents of a 
> NameConstraints extension, and the variable max_path_length (RFC 3280 
> 6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
> today, these variables are set to constants (although that interpretation 
> is not absolutely clear for permitted_subtrees).  In fact, they are three 
> of the four variables which are set to constants during initialization.
>         If permitted subtrees were set to a list of attributes, the 
> validation process would fail if the anchor CA or a CA it certified went 
> beyond the restrictions of those attributes.  Likewise, if the excluded 
> subtrees were set to a list of attributes, the validation process would 
> fail if the anchor CA or a CA it certified went used values matching any 
> of those attributes.  I do not believe that I am arguing against Galileo.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> Sent by: [email-masked]
> 04/29/2004 11:12 PM
> 
>  
>         To:     <[email-masked]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> The basic point (at the risk of repeating myself) is that a CA certificate
> or a self-signed certificate can be used as a means to provide trust 
> anchor
> information.  In that case, there is no need to check signature or 
> anything.
> 
> But, when the CA certificate is a certificate in the certificate path, 
> X.509
> logic kicks in.
> 
> This is consistent with X.509, 3280 and general security principles since
> the trust in a trust anchor can be derived through any number of means.
> 
> If you do not agree, feel free to argue against the definitions and 
> Galileo
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On
> Behalf Of Tom Gindin
> Sent: Thursday, April 29, 2004 8:43 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: RE: Cross certificate format
> 
> 
> 
>         Santosh:
> 
>         I don't think that a CA certificate and a trust anchor are as much 
> 
> 
> different things as different uses for the same thing.  They are both 
> identifiers of issuers which bind a public key to an issuer name, and it 
> is perfectly appropriate for any CA certificate to represent a trust 
> anchor.  I also do not see why such things as name constraints on a trust 
> anchor are inappropriate.  It is perfectly true that verifying a trust 
> anchor's certificate, when issued by another CA (who may not be trusted) 
> is a pointless operation.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> Sent by: [email-masked]
> 04/27/2004 09:14 AM
> 
>  
>         To:     <[email-masked]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> My point is that even if the trust anchor is a self-signed certificate, 
> all
> you need to do is extract the required information.  There is no need to
> examine anything.
> 
> Cross certificate and trust anchor are very different things.  An element 
> of
> the cross certificate pair is nothing but an intermediate CA certificate 
> in
> a certification path.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On
> Behalf Of Tom Gindin
> Sent: Tuesday, April 27, 2004 7:33 AM
> To: Santosh Chokhani
> Cc: [email-masked]; [email-masked]
> Subject: RE: Cross certificate format
> 
> 
> 
>         Santosh:
> 
>         Of course, you are right that RFC 3280 6.1.1 d permits trust 
> anchor information to be provided outside a certificate.  If it is so, no 
> checks of the sort I indicated can be performed.  It also says that it can 
> 
> 
> 
> be provided as "a self-signed certificate", with no further qualification. 
> 
> 
> 
>  I do think it is somewhat odd that a self-signed certificate with 
> KeyUsage set to typical EE values would be considered a valid issuer as a 
> trust anchor while a cross certificate would not.  You can always extract 
> the needed anchor information from a cross-certificate, of course.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> Sent by: [email-masked]
> 04/26/2004 08:51 AM
> 
>  
>         To:     <[email-masked]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> My reading of 3280 and X.509 is that a trust anchor need not even be a
> certificate.  Thus, no checks need to be performed on a trust anchor at 
> all.
> You get the DN, public key, algorithm OID, and parameters (if applicable)
> from a trust anchor.  Any checks are gratuitous and not required by either
> standard.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On
> Behalf Of Tom Gindin
> Sent: Sunday, April 25, 2004 7:06 PM
> To: Jean-Marc Desperrier
> Cc: [email-masked]
> Subject: Re: Cross certificate format
> 
> 
> 
>         Jean-Marc:
> 
>         RFC 3280 doesn't say that anywhere.  It does say that you don't 
> need to validate the trust anchor as part of the path, but it isn't clear 
> from the text that a v1 certificate is acceptable as a trust anchor - and 
> it certainly isn't clear that a v1 certificate is acceptable as an issuer 
> if it is a trust anchor while a v3 certificate with KeyUsage= { 
> DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 
> 
> 
> 
> 
> it is a trust anchor.
>         I believe that the correct rules for versions are something like 
> the following: a certificate issued by a trust anchor which is represented 
> 
> 
> 
> 
> by a certificate is verifiable if the anchor certificate is either a v1 
> certificate or a v3 certificate with the CA flag present in the 
> basicConstraints extension.  If the anchor certificate is a v3 certificate 
> 
> 
> 
> 
> with the KeyUsage extension present, it is only a valid issuer certificate 
> 
> 
> 
> 
> if keyCertSign is set.
> 
>         Tom Gindin
> 
> 
> 
> 
> 
> Jean-Marc Desperrier <[email-masked]>
> Sent by: [email-masked]
> 04/21/2004 03:42 PM
> 
>  
>         To:     [email-masked]
>         cc: 
>         Subject:        Re: Cross certificate format
> 
> 
> 
> 
> Tom Gindin wrote:
> 
> 
>>       RFC 3280 does not support the use of v1 self-signed
>>certificates,
> 
> 
>>which contain no extensions at all (see the text of RFC 3280's 
>>basicConstraints section).  However, a number of public CA's still have 
>>them.
>>
>>
> 
> Applications implementing the path validation algorithm of RFC3280 MUST 
> accept them when they are used as trust anchors.
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

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

--------------ms060201000805020401020705--

Content-class: urn:content-classes:message
Subject: RFC 3280 bug in name constraints
Date: Wed, 5 May 2004 22:07:19 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-6cde8b41-7c06-442b-8e82-16cb7cf52a86
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C432E4.F54FFCD5"

------_=_NextPart_001_01C432E4.F54FFCD5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

If someone is keeping record of bugs for future update of RFC 3280 I
have a small one to file about name constraints.

=20

In section 4.2.1.11, starting at bottom of page 38:

=20

   When rfc822 names are constrained, but the

   certificate does not include a subject alternative name, the rfc822

   name constraint MUST be applied to the attribute of type EmailAddress

   in the subject distinguished name.

=20

Suppose/suggest that the intended meaning is:

=20

   When rfc822 names are constrained, but the certificate does not=20

   include an rfc822Name in a subject alternative name extension, the
rfc822

   name constraint MUST be applied to the attribute of type EmailAddress

   in the subject distinguished name.

=20

=20

Rationale:

Why would the constraint NOT apply to EmailAddress just because there is
a SubjAltName extension with e.g. just some unrelated other name
component present?

=20

/Stefan

=20

------_=_NextPart_001_01C432E4.F54FFCD5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>If someone is keeping record of bugs for =
future update
of RFC 3280 I have a small one to file about name =
constraints.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>In section 4.2.1.11, starting at bottom of =
page 38:<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; When rfc822 names are =
constrained, but
the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; certificate does not include a =
subject
alternative name, the rfc822<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; name constraint MUST be applied =
to the
attribute of type EmailAddress<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; in the =
subject
distinguished name.</span></font><font size=3D2 face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Suppose/suggest that the intended meaning =
is:<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; When rfc822 names are =
constrained, but
the certificate does not <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; include an rfc822Name in a =
subject
alternative name extension, the rfc822<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; name constraint MUST be applied =
to the
attribute of type EmailAddress<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; in the =
subject
distinguished name.</span></font><font size=3D2 face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=

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

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Why would the constraint NOT apply to =
EmailAddress
just because there is a SubjAltName extension with e.g. just some =
unrelated other
name component present?<o:p></o:p></span></font></p>

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

<div>

<div>

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

</div>

</div>

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

</div>

</body>

</html>

------_=_NextPart_001_01C432E4.F54FFCD5--

------=_NextPartTM-000-6cde8b41-7c06-442b-8e82-16cb7cf52a86--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cross certificate format
Date: Wed, 5 May 2004 13:26:15 -0400
Importance: Normal
Sender: [email-masked]

Tom:

I think we agree on what the standards currently do not require any checks.

X.509 is being revised (since I do not keep track of the process -- X.509
change may have been approved for all know) to permit the relying party to
specify these values.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Tuesday, May 04, 2004 11:39 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        Of course, defining a trust anchor implies that the RP trusts the 
anchor's public key as an issuer for at least some purposes.  RFC 3280, in 
the parts of section 6.1.2 I cited, appears to forbid those state 
variables from being set from information defined by the RP or stored with 
the trust anchor.  This is consistent with its statements in 6.1.1 d which 
permit self-signed certificates but say nothing about other CA 
certificates.  As is probably clear to everyone reading this thread, I 
think that this is not an ideal set of suggestions.
        The current standard does contain some constraints on the trust 
anchor (notably inhibit-policy-mapping), but neither name constraints nor 
basic constraints.  I consider this an anomaly.  If I had free rein in 
rewording pieces of RFC 3280 section 6.1, I would change this wording to 
allow CA certificates along with self-signed ones as anchors and create 
extra optional (and optional to support) fields to be set from the trust 
anchor.
        I don't think that this is particularly inconsistent with general 
security principles, or with any part of X.509 with which I am familiar. 
It does represent an extension of RFC 3280 section 6, and it is only 
backward compatible with it, so it may be out of scope.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
05/01/2004 06:46 PM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

The standard does not require you to check how you initialize the 
variables.
You can get these from the cross certificate or from some configuration.

The basic point is that you trust the public key.  How you constrain it is
not address by the standard, where as if the same certificate appeared in 
a
path, you have to apply the constraints or be not compliant with the
standard.

You obviously do not believe in re-incarnation.  Just kidding......

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Saturday, May 01, 2004 6:31 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        It is well known that trust in a trust anchor can be defined in a 
variety of ways.  However, there is every reason to think that an RP may 
constrain that trust and that the constraints he may apply include those 
which an issuer CA may apply to a subordinate one. The wording of RFC 3280 

section 6.2's first paragraph is an example of this.
        My comments about the meaning of a trust anchor are not purely 
theoretical.  If a cross certificate is used to represent a trust anchor, 
the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
(RFC 3280 6.1.2 c) could easily be set from the contents of a 
NameConstraints extension, and the variable max_path_length (RFC 3280 
6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
today, these variables are set to constants (although that interpretation 
is not absolutely clear for permitted_subtrees).  In fact, they are three 
of the four variables which are set to constants during initialization.
        If permitted subtrees were set to a list of attributes, the 
validation process would fail if the anchor CA or a CA it certified went 
beyond the restrictions of those attributes.  Likewise, if the excluded 
subtrees were set to a list of attributes, the validation process would 
fail if the anchor CA or a CA it certified went used values matching any 
of those attributes.  I do not believe that I am arguing against Galileo.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/29/2004 11:12 PM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

The basic point (at the risk of repeating myself) is that a CA certificate
or a self-signed certificate can be used as a means to provide trust 
anchor
information.  In that case, there is no need to check signature or 
anything.

But, when the CA certificate is a certificate in the certificate path, 
X.509
logic kicks in.

This is consistent with X.509, 3280 and general security principles since
the trust in a trust anchor can be derived through any number of means.

If you do not agree, feel free to argue against the definitions and 
Galileo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Thursday, April 29, 2004 8:43 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        I don't think that a CA certificate and a trust anchor are as much 

different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/27/2004 09:14 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 

be provided as "a self-signed certificate", with no further qualification. 

 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/26/2004 08:51 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 

it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 

by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 

with the KeyUsage extension present, it is only a valid issuer certificate 

if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed 
> certificates,

>which contain no extensions at all (see the text of RFC 3280's
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

Date: Wed, 5 May 2004 16:40:37 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: RE: FW: scvp
Cc: [email-masked]
Sender: [email-masked]

- Is there a difference between asking for a key usage of certsign
  and setting the isCA flag?

- For an extendedkeyusage, is the server supposed to chacek whether
  there are the acceptable keyusages in the certificat? I think,
  yes, this should be made more precisely mentioned. 

From: =?iso-8859-1?Q?Carlos_Gonz=E1lez-Cadenas?= <[email-masked]>
To: <[email-masked]>
Subject: DataEncipherment
Date: Wed, 5 May 2004 15:54:26 +0200
Organization: e-xtendforce
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C432B9.3E5430E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

=0D

Just a question about keyUsage DataEncipherment.

=0D

In a RSA-based certificate (the public key included is coming from a RSA=
 key
pair), If I assert the DataEncipherment key usage, I=92m telling to the
relying third parties that my certificate (the public key included into)=
 can
be used for raw data encipherment, but, in the reality, RSA algorithm=
 cannot
be used to cipher large amounts of data (as opposed to a symmetric key, in,
for example, a CBC mode). The common technique with that is to use the
keyEncipherment bit to be able to cipher the symmetric session key used to
cipher the raw data.

=0D

Can anyone point me to the right direction, or provide me some links to
technical documentation, about real-life usages with the Data Encipherment
key usage??. Are there any other technologies/algorithms for RSA where this
key usage has more sense??.

=0D

Thank you very much in advance

Carlos

=0D

Carlos Gonz=E1lez-Cadenas
Jefe de Departamento de Arquitectura Software
Software Architecture Department Manager=0D
Responsable de Seguridad de la Informaci=F3n
Information Security Responsible=0D

e-xtendforce
by e-xtendnow BancSabadell=0D

C/Sena,12 nucli C planta 2
Edifici Landscape
08190 Sant Cugat del Vall=E8s
phone: +34933556139
fax: +34933556142
mailto:  <mailto:[email-masked]>
[email-masked]=0D

=0D

=0D
Advertencia legal:
Este mensaje y, en su caso, los ficheros anexos son confidenciales,
especialmente en lo que respecta a los datos personales, y se dirigen
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha
recibido por error o tiene conocimiento del mismo por cualquier motivo, le
rogamos que nos lo comunique por este medio y proceda a destruirlo o=
 borrarlo,
y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o
comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo=
 pena
de incurrir en responsabilidades legales. El emisor no garantiza la=
 integridad,
rapidez o seguridad del presente correo, ni se responsabiliza de posibles
perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
otras manipulaciones efectuadas por terceros.

=0D
Advertiment legal:
Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial,
especialment pel que fa a les dades personals, i s'adrecen exclusivament al
destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o=
 se li
ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per=
 aquesta
mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui=
 d'utilitzar,
reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers
annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no=
 garanteix
la integritat, la rapidesa o la seguretat d'aquest correu, ni es=
 responsabilitza
de possibles perjudicis derivats de la captura, incorporacions de virus o
qualsevol altres manipulacions que facin tercers.

=0D
Disclaimer:
This message and any attached files transmitted with it, is confidential,
especially as regards personal data. It is intended solely for the use of=
 the
individual or entity to whom it is addressed. If you are not the intended=
 recipient
and have received this information in error or have accessed it for any=
 reason,
please notify us of this fact by email reply and then destroy or delete the=
 message,
refraining from any reproduction, use, alteration, filing or communication=
 to third
parties of this message and attached files on penalty of incurring legal
responsibilities. The sender does not guarantee the integrity, the=
 accuracy, the
swift delivery or the security of this email transmission, and assumes no
responsibility for any possible damage incurred through data capture, virus
incorporation or any manipulation carried out by third parties.
------=_NextPart_000_002A_01C432B9.3E5430E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=
=3Diso-8859-1">

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

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Palatino Linotype";
	panose-1:2 4 5 2 5 5 5 3 3 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Palatino Linotype";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EstiloCorreo17
	{font-family:Arial;
	color:windowtext;}
span.name1
	{font-weight:bold;}
span.logo1
	{font-weight:bold;}
span.textlogo1
	{color:#999999;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>Just a question about keyUsage=
 DataEncipherment.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>In a RSA-based certificate (the public key=
 included
is coming from a RSA key pair), If I assert the DataEncipherment key usage,=
 I&#8217;m
telling to the relying third parties that my certificate (the public key
included into) can be used for raw data encipherment, but, in the reality,=
 RSA
algorithm cannot be used to cipher large amounts of data (as opposed to a
symmetric key, in, for example, a CBC mode). The common technique with that=
 is
to use the keyEncipherment bit to be able to cipher the symmetric session=
 key
used to cipher the raw data.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>Can anyone point me to the right direction, or
provide me some links to technical documentation, about real-life usages=
 with the
Data Encipherment key usage??. Are there any other technologies/algorithms=
 for
RSA where this key usage has more sense??.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>Thank you very much in advance</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'><br>
Carlos</span></font></p>

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

<p class=3DMsoNormal><span class=3Dname1><b><font size=3D2 face=
=3DVerdana><span
style=3D'font-size:10.0pt;font-family:Verdana'>Carlos Gonz=
=E1lez-Cadenas</span></font></b></span><b><font
size=3D2 face=3DVerdana><span style=
=3D'font-size:10.0pt;font-family:Verdana;
font-weight:bold'><br>
</span></font></b><span class=3Dcargo1><font size=3D1 face=3DVerdana><span
style=3D'font-size:8.5pt;font-family:Verdana'>Jefe de Departamento de
Arquitectura Software</span></font></span><font size=3D1 face=
=3DVerdana><span
style=3D'font-size:8.5pt;font-family:Verdana'><br>
<span class=3Dcargo1><i><span style=3D'font-style:italic'>Software=
 Architecture
Department Manager</span></i></span> <br>
<span class=3Dcargo1>Responsable de Seguridad de la Informaci=
=F3n</span><br>
<span class=3Dcargo1><i><span style=3D'font-style:italic'>Information=
 Security
Responsible</span></i></span> <br>
<br>
</span></font><span class=3Dlogo1><b><font size=3D4 face=3DVerdana><span
style=3D'font-size:14.5pt;font-family:Verdana'>e-xtend<font color=
=3D"#0099cc"><span
style=3D'color:#0099CC'>force</span></font></span></font></b></span><font=
 size=3D1
face=3DVerdana><span style=3D'font-size:8.5pt;font-family:Verdana'><br>
</span></font><span class=3Dtextlogo1><font size=3D1 color=3D"#999999" face=
=3DVerdana><span
style=3D'font-size:7.5pt;font-family:Verdana'>by e-xtendnow=
 BancSabadell</span></font></span><font
size=3D1 face=3DVerdana><span style=
=3D'font-size:8.5pt;font-family:Verdana'> <br>
<br>
C/Sena,12 nucli C planta 2<br>
Edifici Landscape<br>
08190 Sant Cugat del Vall=E8s<br>
<u>phone:</u> +34933556139<br>
<u>fax:</u> +34933556142<br>
<u>mailto:</u> <a href=3D"mailto:[email-masked]"><font
color=3Ddarkblue><span style=
=3D'color:darkblue'>[email-masked]</span></font></a>
</span></font></p>

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

</div>

</body>

</html>

<table><tr><td bgcolor=3D#ffffff><font color=3D#000000><pre>=0D
Advertencia legal:
Este mensaje y, en su caso, los ficheros anexos son confidenciales,
especialmente en lo que respecta a los datos personales, y se dirigen
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha
recibido por error o tiene conocimiento del mismo por cualquier motivo, le
rogamos que nos lo comunique por este medio y proceda a destruirlo o=
 borrarlo,
y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o
comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo=
 pena
de incurrir en responsabilidades legales. El emisor no garantiza la=
 integridad,
rapidez o seguridad del presente correo, ni se responsabiliza de posibles
perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
otras manipulaciones efectuadas por terceros.
</pre></font></td></tr></table>
<table><tr><td bgcolor=3D#ffffff><font color=3D#000000><pre>=0D
Advertiment legal:
Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial,
especialment pel que fa a les dades personals, i s'adrecen exclusivament al
destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o=
 se li
ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per=
 aquesta
mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui=
 d'utilitzar,
reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers
annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no=
 garanteix
la integritat, la rapidesa o la seguretat d'aquest correu, ni es=
 responsabilitza
de possibles perjudicis derivats de la captura, incorporacions de virus o
qualsevol altres manipulacions que facin tercers.
</pre></font></td></tr></table>
<table><tr><td bgcolor=3D#ffffff><font color=3D#000000><pre>=0D
Disclaimer:
This message and any attached files transmitted with it, is confidential,
especially as regards personal data. It is intended solely for the use of=
 the
individual or entity to whom it is addressed. If you are not the intended=
 recipient
and have received this information in error or have accessed it for any=
 reason,
please notify us of this fact by email reply and then destroy or delete the=
 message,
refraining from any reproduction, use, alteration, filing or communication=
 to third
parties of this message and attached files on penalty of incurring legal
responsibilities. The sender does not guarantee the integrity, the=
 accuracy, the
swift delivery or the security of this email transmission, and assumes no
responsibility for any possible damage incurred through data capture, virus
incorporation or any manipulation carried out by third parties.
</pre></font></td></tr></table>
------=_NextPart_000_002A_01C432B9.3E5430E0--

From: "Wen-Cheng Wang" <[email-masked]>
To: "PKIX List" <[email-masked]>
Cc: "Steve Hanna" <[email-masked]>
Subject: Re: Comments on Path Building I-D
Date: Wed, 5 May 2004 19:26:29 +0800
Sender: [email-masked]

Dear List,

After reading the certpathbuild draft and the comments
from Steve Hanna, my feeling is that this draft is more
like a paper (or thesis) than a PKIX specification. I believe
that is why Steve criticized the text of the draft as if he is
a reviewer of a PKI paper. I really admire the authors and
Steve's rich and deep knowledge of optimization and
implementation technique for path building. I must confess
that I gained much from reading "the paper" and the
comments from Steve. However, I doubt whether it is
suitable for the PKIX WG to publish "the paper" as an RFC.
I think the text of the draft is good enough to become a
paper on a PKI conference proceedings or even  on a journal.
But, that does not mean it will be a good PKIX RFC.

As a faithful reader of PKIX specifications, I would expect that
if the PKIX WG would like to publish an RFC entitled
"Certification Path Building" then its text should focus on:

1. defining what is a legal certification path
           Can certificates with names in different encoding be chained?
           Can certificates with unmached issuer name and subject name
           be chained by matching SKID and AKID?
2. defining a algorithm for certification path building, also including
         specifying the inputs to the algorithm and
         specifying the outputs from the algorithm
3. specifying the format of certificate/CRL extensions (e.g. SKID, AKID,
    AIA, SIA, CRLDP...) that are related to certification path building.
    E.g.,
           the URL format of different procols (such as LDAP, HTTP, FTP...)
                (e.g., Should the LDAP URL contains the ";binary" option?)
4. specifying how a compliant implementation should process
    theose certificate/CRL extensions related certification path building
5. specifying what is the minimum set of repository retrieving protocols
    (such as LDAP, HTTP, FTP, SMTP...) a compliant implementation
    sould support and how these protocols should be supported. E.g.,
               What is the expected object format?
                    (e.g., DER binary vs.Base64-encoded)
               What is the expected MIME type if HTTP is used?
6. discussing security consideration

I believe that the PKIX certpathbuild specification should specify a
baseline certification path building algorithm in the fashion of RFC
3280 specifying a basic certification path validation algorithm. The
purpose of defining the algorithm is for precisely describe the
expected result of the certification path building. There is no need for
a PKIX specification to teach implementators the optimization and
implementation technique for path building. It is up to the
implementators themselves to choose their own the optimization and
implementation technique. Isn't it?

Therefore, I would like to suggest the authors to complete remove the
section 3 of the current draft. It is not only because a PKIX specification
is not supposed to be a paper or textbook for teaching the optimization
and implementation technique for path building, but also because the
optimization and implementation technique described in that section is
not, as Steve said, the consensus of the PKIX WG. I suggest that the draft
sould spend more space and time to cover the areas I mentioned above.
(I know the current draft already covers them, but I think it is still not
in-depth enough.)

Wen-Cheng Wang

----- Original Message ----- 
From: "Steve Hanna" <[email-masked]>
To: "PKIX List" <[email-masked]>
Sent: Wednesday, April 28, 2004 9:53 PM
Subject: Comments on Path Building I-D

> Here are my comments on draft-ietf-pkix-certpathbuild-03.txt.
> 
> I suspect that these will come off sounding negative.
> I'm sorry about that. I'm glad we have this document
> and I hope it will progress in a modified form, but
> I have some serious problems with the document as
> it now stands.
> 
> I also apologize for the length of these comments.
> I wanted to do a careful review of the document
> and there are a lot of problem areas (although
> some are minor). The fact that nobody else has
> commented on these leads me to suspect that nobody
> except the authors and myself has carefully reviewed
> the document. Can anyone refute that suspicion?
> 
> Thanks,
> 
> Steve
> 
> --------
> 
> Overall Comments:
> 
> * My main overall comment is the one I made last July.
>    There is not consensus on path building techniques
>    in the PKIX working group or the IETF. Why? Because
>    we don't understand the problem thoroughly yet.
> 
>    In this document, you advocate depth first search
>    and suggest that building forward is usually best.
>    I don't think you have carefully considered a wide
>    variety of other algorithms like breadth first search,
>    meet in the middle, etc. Can you show me any solid
>    evidence that shows your algorithms are better than
>    the alternatives?
> 
>    I doubt that you have any such proof. In fact, it
>    seems clear to me that depth first search is a poor
>    algorithm for building cert paths. I say this as a
>    person who has implemented that algorithm myself
>    and regretted it. The problem is that if you make
>    a wrong choice, you must completely explore that
>    part of the PKI before you consider backing out
>    and trying other options. I have heard stories of
>    path building taking 35 minutes or more when there
>    was a valid short path because the builder used
>    DFS and headed down the wrong path.
> 
>    We need to do our homework before making any solid
>    recommendations to implementers. I suppose it's better
>    to have some advice than none, but this document
>    should have a prominent warning that these techniques
>    are experimental. In fact, we might want to give
>    the RFC Experimental status.
> 
>    As I've suggested before, I want to see a careful
>    analysis of different path building strategies.
>    Theoretical analysis will probably be useful,
>    but I expect it will also be useful to compare
>    real-world performance with a variety of topologies
>    (some from real-world deployments, some looking at
>    possible futures like many cross-certified bridges).
>    We need to try out a lot of ideas without getting
>    committed to any too early. The cert path building
>    panel at the PKI R&D Workshop this year was a good
>    start, but we need to do more in-depth work. I've
>    started talking to some other researchers about this.
>    I hope that this documents' authors will join this
>    effort. Their experience and aid will be valuable.
> 
> * At several places in the document, you refer to the
>    "authors' opinions". If this was truly a working
>    group document, it would reflect the consensus of
>    the working group, not the opinions of the authors.
>    As I said before, I don't see working group consensus
>    on this topic. Has anyone other than me (and maybe
>    the authors) carefully reviewed the current draft?
>    I haven't seen any comments on it during Last Call.
> 
>    Since this document does not reflect working group
>    consensus, I do not think it should go forward
>    as a working group draft. It should be an individual
>    submission. But I suppose once it becomes an RFC
>    nobody will ever know whether it was a working group
>    submission or not. And I really do think it's useful
>    to have some guidance on cert path building (even if
>    we don't understand the problem very well). So I'd be
>    OK with having it be a working group submission if it
>    goes to Experimental status and a caveat is added
>    at the beginning warning that this is only the authors'
>    opinion (albeit an educated opinion) and that further
>    study is under way to determine which techniques are
>    actually preferred.
> 
> * You should include in this document a section with
>    guidance to PKI designers about what they can do to
>    make path building easier. Here are some ideas:
> 
>    Use a simple topology (hierarchical with one root),
>    when possible. Include AIA, SIA, and CRLDP extensions
>    in certificates. Make certificates (especially CA
>    certificates) and CRLs easily available by LDAP and
>    HTTP, populating both sides of the crossCertificatePair
>    attribute. Use name constraints and policy constraints
>    whenever possible, especially at high fanout points
>    like bridges. Avoid having more than two high fanout
>    CAs (at most) between any two points, if possible.
> 
> * I have a *serious* objection to the idea that someone
>    is going to specially configure path building software
>    for a particular PKI environment (as I think you imply
>    at the end of section 2.3, early in section 3.4, and in
>    a few other places). This is not practical. Most
>    organizations do not have a PKI wizard on staff
>    (especially a path building wizard). The path building
>    software must just work, automatically. If we can't do
>    that, PKI will never be widely used (at least, not in a
>    non-hierarchical topology). Fortunately, I see no reason
>    why we need special configuration. With AIA and SIA and
>    CRLDP and some good algorithms, we should be able to
>    build paths just fine in almost any PKI without any
>    configuration.
> 
> Substantive Comments:
> 
> * Section 1.2 (Purpose) says "... this document suggests
>    using ... depth first tree traversal. ... Other approaches
>    (e.g., building complete spanning trees of the PKI.) exist
>    and may be shown to be more effective under certain conditions."
> 
>    Building a complete spanning tree of the PKI is not a
>    decent solution. Please change this to something more
>    reasonable, like breadth first search. Otherwise, you're
>    just setting up a straw man, an impractical alternative.
> 
> * In section 1.4.1, you mention one disadvantage of the trust
>    list approach. You might want to mention the problem that
>    compromise of any trusted certificate compromises the
>    entire system.
> 
> * In section 1.4.2, you say that a partial mesh is a mixture
>    of unidirectional and bidirectional cross-certifications.
>    It's probably also important to note that in a partial mesh
>    there may be CAs that are not directly cross-certified at all.
> 
> * What is a Root CA doing in Figure 3? As you say, each EE
>    in a mesh usually trusts the CA that issued its certificate.
>    Because of this Root CA, Figure 3 does not depict a full mesh,
>    as stated in 1.4.2. I suggest that you remove the Root CA.
> 
> * At the end of section 1.4.3, you raise the concern that
>    the assurance of a high-assurance PKI may be diluted by
>    cross-certifying with a less restrictive PKI. If you're
>    going to raise this concern, you should mention that it
>    can be addressed through the use of certificate policies.
> 
> * At the end of section 1.4.4, you say that connecting
>    PKIs with a bridge results in a non-hierarchical PKI.
>    Certainly, this is true. But mesh and hybrid PKIs are
>    not hierarchical either. Why raise this here? And the
>    following sentence which states that any PKI can be
>    considered hierarchical from the right perspective
>    only applies if you remove and duplicate links in the
>    PKI. Since you don't have space to get into this here,
>    I suggest you remove those last two sentences.
> 
> * At the end of the first paragraph of section 2.1, you
>    explain that S/MIME messages commonly include certificates.
>    I think you would be wise to also mention SSL/TLS
>    since this is the most widespread use of PKI and it
>    also supplies certificates in the protocol.
> 
> * Before Figure 6, you explain how certificates are
>    depicted with arrows in your figures. You should also
>    explain the "B(A)" notation you use.
> 
> * At the end of the paragraph after Figure 6, you say
>    that building paths is as important as validating them.
>    I don't agree. Many products have been shipping for
>    years and work just fine without building. In a complex
>    PKI, building is important. But in a simple hierarchical
>    PKI, it's not.
> 
> * At the end of section 2.1, you have a large discussion
>    of why you believe building forward is usually better.
>    This duplicates later discussions on this topic. I suggest
>    you save this for later.
> 
> * In section 2.2, you could simplify and clarify Criterion 1
>    by changing it from this:
> 
>     Criterion 1: The implementation is able to find all possible paths.
>     By this, it is meant that all possible certification paths between
>     the trust anchor and the target certificate which may be valid paths
>     can be built by the algorithm.
> 
>    to this:
> 
>     Criterion 1: The implementation is able to find all possible paths.
>     By this, it is meant that all valid certification paths between
>     the trust anchor and the target certificate can be built by the
>     algorithm.
> 
> * In section 2.2, Criterion 2 seems rather odd. Who cares which
>    invalid paths you build first? The important thing is how quickly
>    and efficiently you can build a valid path or determine that
>    no valid path exists.
> 
> * In section 2.3, you say that because certificates are not
>    permitted to repeat, every potentially valid path has a
>    terminus. But every potentially valid path *always* has
>    a terminus, even if certificates are allowed to repeat.
>    As defined in RFC 3280, a certification path is a collection
>    of n certificates. Every path has a finite number of certificates.
>    I suggest you remove the sentence "As a result, every potential
>    valid path has a terminus, a leaf on the tree."
> 
> * In the following paragraph, you say that removing and
>    duplicating nodes and links in a PKI to turn it into
>    a hierarchy greatly simplifies software design. This
>    may be so, but it also removes many opportunities for
>    insight and optimization. For example, it increases
>    the number of nodes in the data structure and makes it
>    harder to mark a certain area of the PKI as unproductive
>    (since that area may appear several places in the tree).
> 
> * Later in that paragraph, you use the phrase "decision tree"
>    without defining it. I suggest that you define it in
>    section 1.3.
> 
> * One paragraph on page 16 (starting with "A more complicated
>    example") talks about problems with building in the
>    reverse direction when there are many trust anchors.
>    The real issue here is fanout. Whether you're building
>    forward or building reverse, it's bad news when you get
>    to a point where you have several choices. It's especially
>    bad if your heuristics (ranking) don't give you much
>    help in deciding which way to go. And it's even worse
>    if you're using depth-first search, since one wrong
>    move can send you off in the wrong direction for hours.
>    That's why I suggest breadth first search or (even
>    better) ranking all candidates at all points in
>    the tree at each decision time.
> 
>    Four trust anchors is a four-way fanout. A similar
>    situation would arise if you were building forward
>    and arrived at a CA that has four certificates with
>    it as the subject. In either case, you hope that your
>    ranking will help choose the right path. And if you're
>    using depth first search, you really hope that you
>    don't take a wrong turn. One technique for dealing
>    with extreme fanout with fairly equal rankings is to
>    start building from the other end. Another is to rank
>    the certs at the fanout point low and try another branch.
>    A third is to use DPD to get help. And a fourth is to
>    tell PKI designers to use name constraints and other
>    techniques at high fanout points (like bridges) to
>    help path building succeed.
> 
>    I hope that you find this analysis useful.
> 
> * In Figure 10, are W, X, Y, and Z all trust anchors?
>    I think so. That's pretty odd. Why would a relying
>    party have all four of those trust anchors? Who needs
>    the bridge CA in that case? I suspect that this
>    topology was created to support your arguments that
>    repeating a (name, key) pair is bad and that building
>    in reverse is bad. If so, I think you can do better.
> 
>    Let's do a careful theoretical analysis and try
>    out different algorithms on different topologies.
>    I suspect you're right that repeating a (name, key)
>    pair is bad but we need to think about this carefully
>    since it is a significant change to RFC 3280. I think
>    you will see below that building in reverse is a
>    useful tool that should be used in conjunction
>    with building forward. But we need to show the
>    merits of our approaches through analysis, not
>    by consructing topologies that serve our own purposes.
> 
> * In the paragraph after Figure 10, you have several
>    sentences explaining the diagram's notation. This
>    was explained much earlier. The rest of the paragraph
>    (explaining where certificates would be stored in
>    an LDAP directory) also duplicates material found
>    elsewhere. I suggest that you remove these, since
>    the document is already too long.
> 
> * In section 2.4.2, you seem to be proposing that
>    software should build a decision tree. I believe
>    you don't intend for the software to actually
>    build a tree for the entire PKI but only to
>    move incrementally through the PKI adding nodes
>    and links to the tree as needed. I hope that's
>    the case, anyway. Otherwise, you'd need to
>    download all certs in the PKI! If I'm right,
>    you need to be much clearer about this. I could
>    easily imagine a developer writing code that
>    actually builds the tree. That code would
>    work fine in a small test PKI but flood the
>    directory with requests and then die in a
>    large PKI.
> 
> * After Figure 11, you point out that building
>    in reverse is not good in this case. Sure.
>    The EE is in a simple hierarchy. Of course,
>    building forward is best there. If you don't
>    know the topology (especially if you have
>    several trust anchors), starting with forward is
>    fine. Then you can switch or meet in the middle
>    if things get hairy.
> 
> * In section 2.6, you say "[...] the path builder
>    only needs to store the current location in
>    the tree [...] All completed branches can be
>    discarded from memory [...]". Maybe. There's
>    a lot to be said for retaining records of
>    paths you have already tried and rejected.
>    Then you can avoid retrying them at a different
>    point in the graph (unless conditions are
>    sufficiently different to merit a retry).
> 
> * Later in section 2.6, you say "Consider HTTPS
>    support" for CRLDP and AIA. Why would this be
>    valuable? You're retrieving signed data. Using
>    HTTPS may trigger another path build, maybe
>    even a loop where one build triggers another
>    which triggers another and so on. I suppose
>    some repositories may require HTTPS to
>    authenticate the client or protect the
>    certs from prying eyes. But you should probably
>    warn that doing so may be expensive and that
>    implementers should protect against loops.
> 
> * Toward the end of section 2.6, you talk about
>    the path cache. You call for "a configurable
>    expiration date for each entry". Who would
>    configure the date and why? I'm a path building
>    geek and I can't imagine configuring such a
>    thing!
> 
> * A few sentences later, you suggest storing
>    issuer-subject cert relationships. If you
>    want to do this, I suggest that you use a
>    cert hash instead of an (issuer, serial)
>    tuple. Issuer, serial is *not* always unique,
>    especially across multiple PKIs or when
>    one CA is malicious (and remember that some
>    CAs are only partly trusted in a modern PKI).
> 
> * In section 2.7.1, you talk about the required
>    inputs. Instead of supplying the actual Target
>    Certificate, it is sometimes useful to provide
>    criteria that describe what sorts of target
>    certificates you're willing to accept. For instance,
>    when doing S/MIME encryption to a new correspondent
>    you may not have the correspondent's encryption
>    certificate. The path building software can
>    help find it if you tell it what you need.
> 
> * In section 3.2, you recommend that path building
>    software output a detailed log. I think you should
>    recommend that this log be carefully structured
>    so that the paths tried can be easily reconstructed
>    by a diagnostic program. My team built a tool that
>    shows the cert graph and then replays the paths
>    our builder tried, lighting up each one in sequence.
>    We found this a great help in understanding the behavior
>    of our software (finding bugs, improving algorithms,
>    etc.). It's also a very cool way to demo path building,
>    which otherwise is a pretty boring demo ("see, there's
>    the web page!").
> 
> * Later in that paragraph, you say "Ideally, there would
>    be a mechanism for turning this logging on and off [...]".
>    I'd change this to "There should be [...]". Logging is
>    expensive (in storage and CPU time), especially for path
>    building where you commonly try hundreds of certificates
>    or more to create a valid path. You really need a way to
>    turn logging off and on.
> 
> * A few paragraphs later, you say "it may be useful to
>    not rule out any paths" and just return each path as
>    its built, even if it's invalid. The problem with this
>    is that (especially with a depth first search) is that
>    there are many topologies that may cause you to wander
>    among many invalid paths. Why is this technique good?
>    You say it will "provid[e] a more rapid response to the
>    caller than one which builds all possible paths." Maybe.
>    I suspect you'll instead waste time by spending a lot
>    of time returning invalid paths to the caller. I don't
>    see much reason to return invalid paths except in a
>    diagnostic log or for your interesting idea of providing
>    one path that's *mostly* valid for debugging and in case
>    the caller finds that invalid path educational or compelling.
> 
> * A few paragraphs later, you lay out your approach.
>    Here are some comments on it:
> 
>    You say "Do not check revocation status if it requires
>    a directory lookup or network access." Why not start the
>    revocation check and let it run in parallel while you do
>    other things (like checking certs deeper in the graph)?
>    That way, you'll have the revocation check done when you
>    need it. And if the check fails you can abort all work
>    that was based on the validity of that certificate.
>    Of course, you'll want to cache the revocation status
>    of certificates for some time.
> 
>    You say "Do not check digital signatures". Again, why
>    not run this in parallel? Most of path building time
>    (about 90%, based on our data) is spent waiting for
>    the network (while downloading certificates and such).
>    That's an ideal time to be checking signatures. And,
>    of course, you'll want to cache the results of signature
>    checks.
> 
>    You say "Do not check anything that can not be checked
>    as part of the iterative process of traversing the tree."
>    Why not? I expect you would want to run these final checks
>    (like full policy processing when building forward) before
>    returning the path to the caller. Otherwise, the caller
>    will need to run a complete validation of the path, which
>    will take much more time than just running these last
>    few checks.
> 
> * In the last paragraph of 3.2, you say "Second, it is fairly
>    uncommon in typical application environments to encounter
>    a revoked key; therefore, most certificates validated will
>    not be revoked." In a PKI, we don't revoke a key. We revoke
>    a certificate. Therefore, this sentence should read "Second,
>    it is fairly uncommon in typical application environments to
>    encounter a revoked certificate."
> 
> * Why include section 3.3 at all? It's very odd to have
>    an IETF spec talking about internal data structures.
>    Maybe you should just give everyone a copy of your
>    code (since it is apparently ideal) and save them the
>    trouble of implementing it! I'm going to skip my more
>    detailed comments on this section since I think it
>    should be entirely removed.
> 
> * In section 3.4, you refer say "developers should evaluate
>    each method with respect to the environment that the
>    application will operate, and assign weights to each
>    accordingly in the path building software.". First, the
>    word "that" in this sentence should be "in which". Second,
>    this is a prime example of the awful idea that developers
>    must examine each PKI and configure their software to
>    run optimally there.
> 
> * In section 3.5.1, you say "According to [RFC 3280],
>    basicConstraints is required to be present with cA=TRUE
>    in all CA certificates." Actually, section 6.1.4 (k) of
>    RFC 3280 says "Verify that the certificate is a CA
>    certificate (as specified in a basicConstraints extension
>    or as verified out-of-band)." Maybe your software doesn't
>    make any provision for out-of-band indication of CA
>    certificates, but you should probably at least note the
>    possibility that other software may do so.
> 
> * In section 3.5.5, you say "Certificates in the path cache
>    have been validated previously. There is some probability
>    that the path from that certificate to a trust anchor is
>    still valid." The path may still be valid but it may
>    contain constraints that are inconsistent with the
>    path from the Target Certificate to this certificate.
>    You should probably note that possibility.
> 
> * In section 3.5.6, you say that the Previously Verified
>    Signatures sorting method doesn't apply when building
>    in reverse. Actually, it does. Your analysis is incorrect.
>    This method never tells you which way the Target or
>    Trust Anchor is (which certificate is most likely).
>    It only lets you rule out certificates because the
>    signature check would certainly fail.
> 
> * In section 3.5.7, you say the Path Length Constraints
>    sorting method "may be applied in reverse, but the
>    benefit is likely less than that of the forward direction".
>    Why? You can argue that the method is more effective
>    when building in reverse because path length constraints
>    often appear close to trust anchors.
> 
> * In section 3.5.8, you say "Certificates that contain
>    nameConstraints that would  be violated by certificates
>    already in the path to this point are given lower priority
>    (or perhaps eliminated)." They should definitely be
>    eliminated. You know they can't be used to build a
>    valid path, so what's the point (unless you're working
>    on building an invalid path)?
> 
> * In section 3.5.9, you say "While this is viable, the
>    signature verifications required make it less attractive
>    as an elimination method." Usually, a CRL check only
>    requires one signature verification so "verification"
>    should be singular.
> 
>    You also say "It is suggested that this method only
>    be used for sorting and that CRLs are validated post
>    path building." As I noted above, fetching CRLs and
>    performing signature checks can be done in parallel
>    with other work. It's a good idea to do this so that
>    you can discover revoked certs before you have invested
>    too much time in them (and also so that you have the
>    results of the revocation check ASAP).
> 
>    You should also probably change this section to include
>    discussion of OCSP. Right now, it's very focussed on
>    CRLs.
> 
> * Here's a sorting method similar to the "Issuer Found
>    in the Path Cache" method, but better suited to building
>    in reverse. Check whether the subject of the candidate
>    certificate matches the issuer of a certificate sent
>    by the target (in SSL/TLS, S/MIME, etc.). If so, then
>    the candidate certificate should be ranked more
>    highly because it is more likely to lead to a path
>    to the Target Certificate. You may also want to do
>    RDN Matching (as in 3.5.15) with the certificates
>    sent by the target.
> 
> * In section 3.5.15 (on RDN matching), you say "Additionally,
>    it should be noted that this method can require a lot of
>    processing if many trust anchors are present." Actually,
>    this should only require a few hash table lookups (of the
>    RDNs).
> 
> * Section 3.5.18 could be clearer. I think you're saying
>    that the subject and issuer of the candidate certificate
>    should have lots of RDNs in common. But this could be
>    understood to be saying that the subject of the
>    candidate certificate should have lots of RDNs in common
>    with the issuer of the next certificate. Of course,
>    they must match exactly so that can't be what you're
>    saying. But it would help if this section was more
>    explicit.
> 
> * Section 3.5.19 also should be clarified. The description
>    of the reverse method is much clearer than that of the
>    forward method. I suggest that you replace the forward
>    method language with language based on the reverse method
>    language. One change to the reverse method language, though.
>    Instead of saying "If an entity named by a reverse certificate",
>    say "If the subject of a certificate". There's no such
>    thing as a "reverse certificate".
> 
>    Note also that just because you find a name in the
>    certificate cache, that doesn't mean you have the
>    right certificates. There may be several different
>    CAs with the same name. Also, you may now have more
>    clues (like AIA and SIA) for finding certificates
>    than you had before. You should be sure to pursue
>    any such new clues.
> 
> * In the Justification for 3.5.19, you say "The presence of
>    required directory values populated in the cache increases
>    the likelihood that all the required certificates and CRLs
>    needed to complete the path from this certificate to the
>    trust anchor (or target if building in reverse) are present
>    in the cache from a prior path being developed [...]".
>    That's fine, but you might also want to keep the actual path
>    previously developed and look at that as a prime candidate
>    for the path this time.
> 
> * In section 3.5.20, you use the presence of a CRL in
>    the CRL cache to indicate whether a complete path
>    through a CA has previously been found. This is
>    rather indirect. It would be better to actually
>    track which certs have been previously included
>    in valid paths. Keeping a copy of the path would
>    also be quite useful.
> 
> * The discussion of Forward Policy Chaining in section 4
>    overstates the benefits of policy checks when building
>    in the forward direction. We should discuss this more.
> 
> * In section 5.2, you suggest that each name/key pair
>    only be allowed to appear once in a path. Since there
>    is no such requirement in X.509 or RFC 3280, this
>    would violate Criterion 1 as stated in section 2.2.
>    You would miss some valid paths.
> 
> * In section 6 (Retrieval Methods), you should mention
>    getting certificates and CRLs from the target (with
>    S/MIME or SSL/TLS, for instance). That's a *great*
>    way to get certificates and CRLs. The ones you get
>    are usually highly valuable.
> 
> * Sections 6.2 and 6.3 should include text that encourages
>    implementers to support AIA and SIA, especially HTTP.
>    This text from the end of section 6.4 could easily
>    be adapted:
> 
>        However, implementers of path building
>     and validation modules are strongly encouraged to support CRLDPs.  At
>     a minimum, developers are encouraged to consider supporting the LDAP
>     and HTTP transports; this will provide for interoperability across a
>     wide range of existing PKIs.
> 
> * In section 7, you should talk about prefetching and
>    parallel fetching. Both are good ways to improve the
>    performance of a cert path building implementation.
> 
> * In section 7.1, you say "Certificate processing systems can
>    cache data retrieved from external sources for some period
>    of time, but not to exceed the useful period of the data
>    (i.e., an expired certificate need not be cached)." CRLs
>    are often issued well before the nextUpdate of the previous
>    CRL. Could you mention this and suggest that implementers
>    check periodically for updated CRLs? Similarly,
>    crossCertificatePairs may be updated on an unpredictable
>    basis. If you don't check back every so often, you'll
>    never know that a new cross certificate is available!
> 
> * The last bullet in section 7.1 offers a few suggestions
>    for other things to cache. I'd add to that list previously
>    built paths and partial paths. If the cache is safe from
>    unauthorized modifications (as with an in-memory cache),
>    you may also want to cache validation and signature check
>    status for certificates and CRLs.
> 
> * In section 7.2 (Retrieval Order), you may want to consider
>    checking repositories in parallel instead of serially.
>    Also, you might want to run ahead with your path building
>    and validation while a network query is ongoing. Maybe
>    you can build and validate the path with just the certificates
>    and CRLs you have already (thus eliminating the need to
>    wait for the network query to complete). Anything to get
>    the answer to the user more quickly!
> 
> * In section 8.1, you should probably add a statement that
>    path building can be used as a denial of service attack.
>    Make a series of simple requests to a server and cause it
>    to do a bunch of long path builds. To avoid this, the
>    server can limit the amount of resources it's willing to
>    devote to a path build. This amount can be reduced when
>    the load is heavy. And standard DOS protections like
>    identifying attackers can be employed.
> 
> * Section 8.2 goes way beyond RFC 3280 and X.509. I know
>    that Santosh is working on getting this into X.509 and
>    the successor to RFC 3280. I'll debate the specifics
>    of his proposal in that context. But for this document,
>    I think you should be careful to explain that this goes
>    beyond the standards. If you implement it, you will
>    violate Criterion 1 from section 2.2. Maybe the best
>    thing to do is to just briefly point out that there's
>    an issue here and it's under discussion in the standards
>    groups. Once it's settled there, this document can be
>    revised to reflect whatever's agreed on.
> 
> Minor Comments:
> 
> * The first paragraph of section 2 says "... guidance is
>    provided on the capabilities path building implementations
>    required in order to ...". I think you want "require" or
>    (maybe better due to RFC 2119) "need" instead of "required".
> 
> * Just below Figure 6, "the certificates cannot be validated"
>    should be "certificates cannot be validated". You're not
>    referring to any particular certificates, just certificates
>    in general.
> 
> * In the paragraph after that, you should say "the
>    crossCertificatePair attribute" instead of "the cross
>    certificates". Otherwise, it's not clear what you mean.
> 
> * In the second paragraph of section 3.2, you say a
>    certificate "may appear again on another point in
>    the tree". That should be "at another point in
>    the tree".
> 
> * At the end of section 3.4, "The list" should be "the list".
> 
> * In section 3.5.17, there are two typos. "it priority"
>    should be "it has priority". "will not successfully"
>    (in the last paragraph) should be "will not verify
>    successfully".
> 
> * In section 5.4, you say certificates "will be" required
>    to use UTF-8 after January 1, 2004. This should now
>    be changed to "are".
> 
> * In section 6, the first sentence should mention CRLs
>    also. I suggest that the second sentence say "obtaining
>    these certificates and CRLs" instead of "performing
>    this retrieval", since retrieval has not yet been
>    mentioned and sometimes the certificates can be
>    obtained without having to be retrieved (as when the
>    EE sends them in SSL).
> 
> * In section 6.1, the description of userCertificate
>    should probably say that it "contains certificates
>    issued by one or more certification authorities with
>    a subject DN that matches that of the directory entry".
>    Also, there's an extra period at the end of the
>    parenthetical comment later in the paragraph.
> 
> * Later in section 6.1, the description of issuedByThisCA
>    should say it contains certificates issued to *other*
>    CAs. And there's an extra comma after "If both elements
>    are present" (later in that paragraph). Why include that
>    sentence anyway. The relying party doesn't need to
>    enforce this requirement. People may think they need
>    to do so.
> 
> * In section 6.2, you say "AIA may be used to retrieve one or
>    more certificates for entities that issued the certificate
>    containing the AIA extension." I think it would be clearer
>    to say "the CA" instead of "entities".
> 
> * At the end of the first paragraph of section 6.3, "AIA"
>    appears twice where it should be "SIA".
> 
> * In section 6.4, you say "the CRL(s) to which the CRLDP(s) refer
>    is the CRL that would contain revocation information for the
>    certificate." I'd say instead "the CRL(s) to which the CRLDP
>    refers are generally the CRLs that would contain revocation
>    information for the certificate." Why? Because a CRLDP may
>    refer an LDAP directory entry that contains many CRLs. Some
>    of them may not pertain to this certificate. And of course
>    there's usually only one CRLDP in a certificate.
> 
> * In section 8.2, "q CRL Signer" should be "a CRL Signer".
> 
> * In the Informative References, you include "[MINHPKIS]"
>    but it's never actually referred to anywhere in the document.
>    Similarly for [X.501] and [X.520]. You should probably
>    remove those references. If you're going to retain them
>    for some reason, please provide a decent reference for
>    [MINHPKIS]: publisher, publication date.
> 

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked]
Subject: RE: Cross certificate format
From: Tom Gindin <[email-masked]>
Date: Tue, 4 May 2004 23:39:26 -0400
Sender: [email-masked]

        Santosh:

        Of course, defining a trust anchor implies that the RP trusts the 
anchor's public key as an issuer for at least some purposes.  RFC 3280, in 
the parts of section 6.1.2 I cited, appears to forbid those state 
variables from being set from information defined by the RP or stored with 
the trust anchor.  This is consistent with its statements in 6.1.1 d which 
permit self-signed certificates but say nothing about other CA 
certificates.  As is probably clear to everyone reading this thread, I 
think that this is not an ideal set of suggestions.
        The current standard does contain some constraints on the trust 
anchor (notably inhibit-policy-mapping), but neither name constraints nor 
basic constraints.  I consider this an anomaly.  If I had free rein in 
rewording pieces of RFC 3280 section 6.1, I would change this wording to 
allow CA certificates along with self-signed ones as anchors and create 
extra optional (and optional to support) fields to be set from the trust 
anchor.
        I don't think that this is particularly inconsistent with general 
security principles, or with any part of X.509 with which I am familiar. 
It does represent an extension of RFC 3280 section 6, and it is only 
backward compatible with it, so it may be out of scope.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
05/01/2004 06:46 PM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

The standard does not require you to check how you initialize the 
variables.
You can get these from the cross certificate or from some configuration.

The basic point is that you trust the public key.  How you constrain it is
not address by the standard, where as if the same certificate appeared in 
a
path, you have to apply the constraints or be not compliant with the
standard.

You obviously do not believe in re-incarnation.  Just kidding......

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Saturday, May 01, 2004 6:31 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        It is well known that trust in a trust anchor can be defined in a 
variety of ways.  However, there is every reason to think that an RP may 
constrain that trust and that the constraints he may apply include those 
which an issuer CA may apply to a subordinate one. The wording of RFC 3280 

section 6.2's first paragraph is an example of this.
        My comments about the meaning of a trust anchor are not purely 
theoretical.  If a cross certificate is used to represent a trust anchor, 
the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
(RFC 3280 6.1.2 c) could easily be set from the contents of a 
NameConstraints extension, and the variable max_path_length (RFC 3280 
6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
today, these variables are set to constants (although that interpretation 
is not absolutely clear for permitted_subtrees).  In fact, they are three 
of the four variables which are set to constants during initialization.
        If permitted subtrees were set to a list of attributes, the 
validation process would fail if the anchor CA or a CA it certified went 
beyond the restrictions of those attributes.  Likewise, if the excluded 
subtrees were set to a list of attributes, the validation process would 
fail if the anchor CA or a CA it certified went used values matching any 
of those attributes.  I do not believe that I am arguing against Galileo.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/29/2004 11:12 PM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

The basic point (at the risk of repeating myself) is that a CA certificate
or a self-signed certificate can be used as a means to provide trust 
anchor
information.  In that case, there is no need to check signature or 
anything.

But, when the CA certificate is a certificate in the certificate path, 
X.509
logic kicks in.

This is consistent with X.509, 3280 and general security principles since
the trust in a trust anchor can be derived through any number of means.

If you do not agree, feel free to argue against the definitions and 
Galileo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Thursday, April 29, 2004 8:43 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        I don't think that a CA certificate and a trust anchor are as much 

different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/27/2004 09:14 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 

be provided as "a self-signed certificate", with no further qualification. 

 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/26/2004 08:51 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 

it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 

by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 

with the KeyUsage extension present, it is only a valid issuer certificate 

if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed
> certificates,

>which contain no extensions at all (see the text of RFC 3280's 
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

Content-class: urn:content-classes:message
Subject: RE: FW: scvp
Date: Tue, 4 May 2004 10:22:07 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Denis,
There is no mandate in 3379 that a validation policy must be expressed
with a single value. It is not clear that is any value is doing so since
it only raised more ambiguity. This is well trod turf by many groups who
have debated the merits of providing suits vs. "al a carte" combinations
of inputs and the broader consensus is for a "al a carte".
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, May 04, 2004 3:15 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: FW: scvp

Trevor,

> Hi Denis,
> 
> 3379 does not require that the validation policy be specified in a
> single value. 

You are playing with words. The text says:
"most clients will simply reference a validation policy"

This means that validation policies can be referenced and thus
parameters do 
not need to be defined through this interface.

A simple and good reference is an OID.

> With SCVP14 a client can accept the default of the SCVP
> server or specify a set of parameters which constitutes its validation
> policy. That is consistent with the requirements of 3379.

The specification of the set of parameters should be done through a 
different interface. This different interface can then return an OID 
Whatever this additional interface can be, it will never be rich enough
to 
pass all the details of the validation policy. Thus OIDs can also be
defined 
not using this additional interface.

Denis

> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Thursday, April 29, 2004 3:54 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> 
>>Hi Denis,
> 
> 
>>Can you please be more specific how you think SCVP 14 does not comply
>>with 3379.
>>
>>I can find no section in 3379 where is there a requirement that a
>>validation policy MUST be represented as an OID. 
> 
> 
> There cannot be a requirement with such a level of detail, but the
text
> states:
> 
>     The protocol MUST allow the client to include
>     these policy dependant parameters in the DPV request; however, it
is
>     expected that most clients will simply reference a validation
policy
>     for a given application or accept the DPV server's default
> validation
>     policy.
> 
> A simple reference is an OID.
> 
> FYI, I do not expect to use the "default validation policy".
> 
> Denis
> 
> 
> 
>>Given hiding the detail of what a policy is within an OID simply opens
>>the rat hole of what change to the policy constitutes a change to the
>>OID, it is less ambiguous to refer to the primary data. Once you are
> 
> in
> 
>>the business of managing state on a client, then there is negligible
>>cost increase incurred in managing several data points vs. a singe
> 
> data
> 
>>point.
>>
>>Trevor
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[email-masked]] 
>>Sent: Tuesday, April 27, 2004 11:01 AM
>>To: Trevor Freeman
>>Cc: [email-masked]
>>Subject: Re: FW: scvp
>>
>>Trevor,
>>
>>
>>
>>>HI Denis,
>>>In SCVP13, the concept of validation policy was not completely in
>>>alignment  with 3379 definition. 
>>
>>
>>Well, it is different and this is a major problem.
>>
>>
>>
>>>It also blurred the distinction between
>>>validation policy and validation algorithm. 
>>
>>
>>This is also a majo problem.
>>
>>
>>
>>>Therefore I have defined
>>>what each is in SCVP 14 and aligned the structures accordingly.
>>>Section 1.3 has the following.
>>>"In SCVP, the validation policy comprises of an algorithm for
>>>certificate path processing and the input parameters to the
>>
>>algorithm."
>>
>>This does not comply with RFC 3379.
>>
>>
>>
>>>Therefore trust anchors are an input into the algorithm  and
therefore
>>>separate.
>>
>>
>>Therefore I do not follow you.
>>
>> From an interface point of view the simplest validation policy is
>>defined 
>>by an OID where all the parameters necessary to perform the validation
>>check 
>>are "behind" the OID. There is no need to provide any parameter
> 
> through
> 
>>the 
>>interface.
>>
>>When there are some parameters, then they are specific to the
> 
> validation
> 
>>policy. I have no problem to provide specific parameters for what is
>>called 
>>the "default validation policy" which is only a particular validation
>>policy 
>>among many others.
>>
>>Simple clients will be unable to pass any parameter but will know
> 
> which
> 
>>OIDs 
>>(for the validation policy) are appropriate for their applications.
>>
>>Denis
>>
>>
>>
>>>This is in alignment with 3379s definition of validation policy.
>>>
>>>Trevor
>>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[email-masked]] 
>>>Sent: Monday, April 26, 2004 1:09 AM
>>>To: Peter Sylvester
>>>Cc: [email-masked]; Trevor Freeman
>>>Subject: Re: FW: scvp
>>>
>>>Peter and Trevor,
>>>
>>>I have major problems too.
>>>
>>>
>>>
>>>
>>>>in version 13 the syntax for a Query has been changed from
>>>>
>>>> Query ::= SEQUENCE { 
>>>>     queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>>>     checks                CertChecks, 
>>>>     wantBack              WantBack, 
>>>>     serverContextInfo [0] OCTET STRING OPTIONAL, 
>>>>     valPolicy         [1] ValidationPolicy OPTIONAL, 
>>>>     validityTime      [2] GeneralizedTime OPTIONAL, 
>>>>     trustAnchors      [3] TrustAnchors OPTIONAL, 
>>>>     intermediateCerts [4] CertBundle OPTIONAL, 
>>>>     revInfos          [5] RevocationInfos OPTIONAL, 
>>>>     queryExtensions   [6] Extensions OPTIONAL } 
>>>
>>>
>>>In this structure trustAnchors was more or less an alternative to
>>>valPolicy.
>>>
>>>In fact, IF the valPolicy is the default policy, THEN additional
>>>parameters 
>>>MUST be provided. So the structure below does not fit as well.
>>>
>>>This leads to have the two following elements:
>>>
>>>    valPolicy               ValidationPolicy,
>>>    paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
>>>
>>>where the first one is mandatory and the second one optional.
>>>
>>>
>>>
>>>
>>>>to  
>>>>
>>>>  Query ::= SEQUENCE { 
>>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>
>>>
>>>>    checks                  CertChecks, 
>>>>    wantBack                WantBack, 
>>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>    valAlgorithm            ValidationAlgorithm, 
>>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>    revInfos            [4] RevocationInfos OPTIONAL, 
>>>>    queryExtensions     [5] Extensions OPTIONAL } 
>>>
>>>
>>>I would thus propose to have something like:
>>>
>>>Query ::= SEQUENCE {
>>>        queriedCerts            SEQUENCE SIZE (1..MAX) OF
>>>CertReference,
>>>        checks                  CertChecks,
>>>        wantBack                WantBack,
>>>        requestRefHash          BOOLEAN DEFAULT TRUE,
>>>        serverContextInfo       OCTET STRING OPTIONAL,
>>>        validityTime            GeneralizedTime OPTIONAL,
>>>        includePolResponse      BOOLEAN DEFAULT FALSE,
>>>        valPolicy               ValidationPolicy,
>>>        paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>>>        intermediateCerts   [1] CertBundle OPTIONAL,
>>>        revInfos            [2] RevocationInfos OPTIONAL,
>>>        queryExtensions     [3] Extensions OPTIONAL }
>>>
>>>and then something like:
>>>
>>>   ParamsDefValPolicy :: = SEQUENCE {
>>>       trustAnchors                  TrustAnchors,
>>>       endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
>>>OPTIONAL,
>>>       inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>>>       caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
>>>OPTIONAL }
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>>I am not sure whether I am the only person unable to construct a
>>>
>>>parser.
>>>
>>>
>>>
>>>>in version 14 an aditional flag has been added which is not
available
>>>
>>>in the
>>>
>>>
>>>
>>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
>>>
> validation
> 
>>>>algorithms, or just to some of them, e.g,. the default name matching
>>>
>>>one? 
>>>
>>>
>>>
>>>>  Query ::= SEQUENCE { 
>>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>
>>>
>>>>    checks                  CertChecks, 
>>>>    wantBack                WantBack, 
>>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>    isCA                    BOOLEAN DEFAULT FALSE, 
>>>>    valAlgorithm            ValidationAlgorithm, 
>>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>    revInfos            [4] RevocationInfos OPTIONAL, 
>>>>    keyUsage            [5] KeyUsage OPTIONAL, 
>>>>    extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>>>    queryExtensions     [7] Extensions OPTIONAL  
>>>>    producedAt          [8] GeneralizedTime OPTIONAL} 
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 

Date: Tue, 04 May 2004 12:15:28 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
Subject: Re: FW: scvp
Sender: [email-masked]

Trevor,

> Hi Denis,
> 
> 3379 does not require that the validation policy be specified in a
> single value. 

You are playing with words. The text says:
"most clients will simply reference a validation policy"

This means that validation policies can be referenced and thus parameters do 
not need to be defined through this interface.

A simple and good reference is an OID.

> With SCVP14 a client can accept the default of the SCVP
> server or specify a set of parameters which constitutes its validation
> policy. That is consistent with the requirements of 3379.

The specification of the set of parameters should be done through a 
different interface. This different interface can then return an OID 
Whatever this additional interface can be, it will never be rich enough to 
pass all the details of the validation policy. Thus OIDs can also be defined 
not using this additional interface.

Denis

> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Thursday, April 29, 2004 3:54 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> 
>>Hi Denis,
> 
> 
>>Can you please be more specific how you think SCVP 14 does not comply
>>with 3379.
>>
>>I can find no section in 3379 where is there a requirement that a
>>validation policy MUST be represented as an OID. 
> 
> 
> There cannot be a requirement with such a level of detail, but the text
> states:
> 
>     The protocol MUST allow the client to include
>     these policy dependant parameters in the DPV request; however, it is
>     expected that most clients will simply reference a validation policy
>     for a given application or accept the DPV server's default
> validation
>     policy.
> 
> A simple reference is an OID.
> 
> FYI, I do not expect to use the "default validation policy".
> 
> Denis
> 
> 
> 
>>Given hiding the detail of what a policy is within an OID simply opens
>>the rat hole of what change to the policy constitutes a change to the
>>OID, it is less ambiguous to refer to the primary data. Once you are
> 
> in
> 
>>the business of managing state on a client, then there is negligible
>>cost increase incurred in managing several data points vs. a singe
> 
> data
> 
>>point.
>>
>>Trevor
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[email-masked]] 
>>Sent: Tuesday, April 27, 2004 11:01 AM
>>To: Trevor Freeman
>>Cc: [email-masked]
>>Subject: Re: FW: scvp
>>
>>Trevor,
>>
>>
>>
>>>HI Denis,
>>>In SCVP13, the concept of validation policy was not completely in
>>>alignment  with 3379 definition. 
>>
>>
>>Well, it is different and this is a major problem.
>>
>>
>>
>>>It also blurred the distinction between
>>>validation policy and validation algorithm. 
>>
>>
>>This is also a majo problem.
>>
>>
>>
>>>Therefore I have defined
>>>what each is in SCVP 14 and aligned the structures accordingly.
>>>Section 1.3 has the following.
>>>"In SCVP, the validation policy comprises of an algorithm for
>>>certificate path processing and the input parameters to the
>>
>>algorithm."
>>
>>This does not comply with RFC 3379.
>>
>>
>>
>>>Therefore trust anchors are an input into the algorithm  and therefore
>>>separate.
>>
>>
>>Therefore I do not follow you.
>>
>> From an interface point of view the simplest validation policy is
>>defined 
>>by an OID where all the parameters necessary to perform the validation
>>check 
>>are "behind" the OID. There is no need to provide any parameter
> 
> through
> 
>>the 
>>interface.
>>
>>When there are some parameters, then they are specific to the
> 
> validation
> 
>>policy. I have no problem to provide specific parameters for what is
>>called 
>>the "default validation policy" which is only a particular validation
>>policy 
>>among many others.
>>
>>Simple clients will be unable to pass any parameter but will know
> 
> which
> 
>>OIDs 
>>(for the validation policy) are appropriate for their applications.
>>
>>Denis
>>
>>
>>
>>>This is in alignment with 3379s definition of validation policy.
>>>
>>>Trevor
>>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[email-masked]] 
>>>Sent: Monday, April 26, 2004 1:09 AM
>>>To: Peter Sylvester
>>>Cc: [email-masked]; Trevor Freeman
>>>Subject: Re: FW: scvp
>>>
>>>Peter and Trevor,
>>>
>>>I have major problems too.
>>>
>>>
>>>
>>>
>>>>in version 13 the syntax for a Query has been changed from
>>>>
>>>> Query ::= SEQUENCE { 
>>>>     queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>>>     checks                CertChecks, 
>>>>     wantBack              WantBack, 
>>>>     serverContextInfo [0] OCTET STRING OPTIONAL, 
>>>>     valPolicy         [1] ValidationPolicy OPTIONAL, 
>>>>     validityTime      [2] GeneralizedTime OPTIONAL, 
>>>>     trustAnchors      [3] TrustAnchors OPTIONAL, 
>>>>     intermediateCerts [4] CertBundle OPTIONAL, 
>>>>     revInfos          [5] RevocationInfos OPTIONAL, 
>>>>     queryExtensions   [6] Extensions OPTIONAL } 
>>>
>>>
>>>In this structure trustAnchors was more or less an alternative to
>>>valPolicy.
>>>
>>>In fact, IF the valPolicy is the default policy, THEN additional
>>>parameters 
>>>MUST be provided. So the structure below does not fit as well.
>>>
>>>This leads to have the two following elements:
>>>
>>>    valPolicy               ValidationPolicy,
>>>    paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
>>>
>>>where the first one is mandatory and the second one optional.
>>>
>>>
>>>
>>>
>>>>to  
>>>>
>>>>  Query ::= SEQUENCE { 
>>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>
>>>
>>>>    checks                  CertChecks, 
>>>>    wantBack                WantBack, 
>>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>    valAlgorithm            ValidationAlgorithm, 
>>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>    revInfos            [4] RevocationInfos OPTIONAL, 
>>>>    queryExtensions     [5] Extensions OPTIONAL } 
>>>
>>>
>>>I would thus propose to have something like:
>>>
>>>Query ::= SEQUENCE {
>>>        queriedCerts            SEQUENCE SIZE (1..MAX) OF
>>>CertReference,
>>>        checks                  CertChecks,
>>>        wantBack                WantBack,
>>>        requestRefHash          BOOLEAN DEFAULT TRUE,
>>>        serverContextInfo       OCTET STRING OPTIONAL,
>>>        validityTime            GeneralizedTime OPTIONAL,
>>>        includePolResponse      BOOLEAN DEFAULT FALSE,
>>>        valPolicy               ValidationPolicy,
>>>        paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>>>        intermediateCerts   [1] CertBundle OPTIONAL,
>>>        revInfos            [2] RevocationInfos OPTIONAL,
>>>        queryExtensions     [3] Extensions OPTIONAL }
>>>
>>>and then something like:
>>>
>>>   ParamsDefValPolicy :: = SEQUENCE {
>>>       trustAnchors                  TrustAnchors,
>>>       endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
>>>OPTIONAL,
>>>       inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>>>       caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
>>>OPTIONAL }
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>>I am not sure whether I am the only person unable to construct a
>>>
>>>parser.
>>>
>>>
>>>
>>>>in version 14 an aditional flag has been added which is not available
>>>
>>>in the
>>>
>>>
>>>
>>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
>>>
> validation
> 
>>>>algorithms, or just to some of them, e.g,. the default name matching
>>>
>>>one? 
>>>
>>>
>>>
>>>>  Query ::= SEQUENCE { 
>>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>
>>>
>>>>    checks                  CertChecks, 
>>>>    wantBack                WantBack, 
>>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>    isCA                    BOOLEAN DEFAULT FALSE, 
>>>>    valAlgorithm            ValidationAlgorithm, 
>>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>    revInfos            [4] RevocationInfos OPTIONAL, 
>>>>    keyUsage            [5] KeyUsage OPTIONAL, 
>>>>    extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>>>    queryExtensions     [7] Extensions OPTIONAL  
>>>>    producedAt          [8] GeneralizedTime OPTIONAL} 
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cross certificate format
Date: Sat, 1 May 2004 18:46:26 -0400
Importance: Normal
Sender: [email-masked]

Tom:

The standard does not require you to check how you initialize the variables.
You can get these from the cross certificate or from some configuration.

The basic point is that you trust the public key.  How you constrain it is
not address by the standard, where as if the same certificate appeared in a
path, you have to apply the constraints or be not compliant with the
standard.

You obviously do not believe in re-incarnation.  Just kidding......

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Saturday, May 01, 2004 6:31 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        It is well known that trust in a trust anchor can be defined in a 
variety of ways.  However, there is every reason to think that an RP may 
constrain that trust and that the constraints he may apply include those 
which an issuer CA may apply to a subordinate one. The wording of RFC 3280 
section 6.2's first paragraph is an example of this.
        My comments about the meaning of a trust anchor are not purely 
theoretical.  If a cross certificate is used to represent a trust anchor, 
the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
(RFC 3280 6.1.2 c) could easily be set from the contents of a 
NameConstraints extension, and the variable max_path_length (RFC 3280 
6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
today, these variables are set to constants (although that interpretation 
is not absolutely clear for permitted_subtrees).  In fact, they are three 
of the four variables which are set to constants during initialization.
        If permitted subtrees were set to a list of attributes, the 
validation process would fail if the anchor CA or a CA it certified went 
beyond the restrictions of those attributes.  Likewise, if the excluded 
subtrees were set to a list of attributes, the validation process would 
fail if the anchor CA or a CA it certified went used values matching any 
of those attributes.  I do not believe that I am arguing against Galileo.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/29/2004 11:12 PM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

The basic point (at the risk of repeating myself) is that a CA certificate
or a self-signed certificate can be used as a means to provide trust 
anchor
information.  In that case, there is no need to check signature or 
anything.

But, when the CA certificate is a certificate in the certificate path, 
X.509
logic kicks in.

This is consistent with X.509, 3280 and general security principles since
the trust in a trust anchor can be derived through any number of means.

If you do not agree, feel free to argue against the definitions and 
Galileo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Thursday, April 29, 2004 8:43 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        I don't think that a CA certificate and a trust anchor are as much 

different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/27/2004 09:14 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 

be provided as "a self-signed certificate", with no further qualification. 

 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/26/2004 08:51 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 

it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 

by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 

with the KeyUsage extension present, it is only a valid issuer certificate 

if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed
> certificates,

>which contain no extensions at all (see the text of RFC 3280's 
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked]
Subject: RE: Cross certificate format
From: Tom Gindin <[email-masked]>
Date: Sat, 1 May 2004 18:30:55 -0400
Sender: [email-masked]

        Santosh:

        It is well known that trust in a trust anchor can be defined in a 
variety of ways.  However, there is every reason to think that an RP may 
constrain that trust and that the constraints he may apply include those 
which an issuer CA may apply to a subordinate one. The wording of RFC 3280 
section 6.2's first paragraph is an example of this.
        My comments about the meaning of a trust anchor are not purely 
theoretical.  If a cross certificate is used to represent a trust anchor, 
the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
(RFC 3280 6.1.2 c) could easily be set from the contents of a 
NameConstraints extension, and the variable max_path_length (RFC 3280 
6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
today, these variables are set to constants (although that interpretation 
is not absolutely clear for permitted_subtrees).  In fact, they are three 
of the four variables which are set to constants during initialization.
        If permitted subtrees were set to a list of attributes, the 
validation process would fail if the anchor CA or a CA it certified went 
beyond the restrictions of those attributes.  Likewise, if the excluded 
subtrees were set to a list of attributes, the validation process would 
fail if the anchor CA or a CA it certified went used values matching any 
of those attributes.  I do not believe that I am arguing against Galileo.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/29/2004 11:12 PM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

The basic point (at the risk of repeating myself) is that a CA certificate
or a self-signed certificate can be used as a means to provide trust 
anchor
information.  In that case, there is no need to check signature or 
anything.

But, when the CA certificate is a certificate in the certificate path, 
X.509
logic kicks in.

This is consistent with X.509, 3280 and general security principles since
the trust in a trust anchor can be derived through any number of means.

If you do not agree, feel free to argue against the definitions and 
Galileo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Thursday, April 29, 2004 8:43 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        I don't think that a CA certificate and a trust anchor are as much 

different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/27/2004 09:14 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 

be provided as "a self-signed certificate", with no further qualification. 

 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/26/2004 08:51 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 

it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 

by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 

with the KeyUsage extension present, it is only a valid issuer certificate 

if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed 
> certificates,

>which contain no extensions at all (see the text of RFC 3280's
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.