WG Last Call closed: PK algs

[[e-mail]]

Folks,

Last Call for "Additional Algorithms and Identifiers for RSA Cryptography 
for use in the Internet X.509 Public Key Infrastructure" has been successfully 
completed.  All technical issues raised on the list have been resolved in the 
current draft, available at

  http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-02.txt

As a result, I am forwarding the document to the ADs and requesting 
progression as a standards track RFC.

Thanks,

Tim Polk




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TGnOt7037105; Sun, 29 Feb 2004 08:49:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1TGnOMZ037104; Sun, 29 Feb 2004 08:49:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from webmail.nist.gov (rimp2.nist.gov [129.6.16.227]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TGnMKT037095 for <[e-mail]>; Sun, 29 Feb 2004 08:49:23 -0800 (PST) (envelope-from [e-mail])
Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by webmail.nist.gov (8.12.8/8.12.8) with ESMTP id i1TGnKF7029831; Sun, 29 Feb 2004 11:49:20 -0500
Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id i1TGnJSn029829; Sun, 29 Feb 2004 11:49:19 -0500
Received: from pool-141-156-251-147.res.east.verizon.net (pool-141-156-251-147.res.east.verizon.net [141.156.251.147])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Sun, 29 Feb 2004 11:49:19 -0500
Message-ID: <[e-mail]>
Date: Sun, 29 Feb 2004 11:49:19 -0500
From: [e-mail]
To: [e-mail], [e-mail]
Cc: Steven Bellovin <[e-mail]>, Russell Housley <[e-mail]>
Subject: WG Last Call closed: PK algs
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 141.156.251.147
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Last Call for "Additional Algorithms and Identifiers for RSA Cryptography 
for use in the Internet X.509 Public Key Infrastructure" has been successfully 
completed.  All technical issues raised on the list have been resolved in the 
current draft, available at

  http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-02.txt

As a result, I am forwarding the document to the ADs and requesting 
progression as a standards track RFC.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1S46mvI074629; Fri, 27 Feb 2004 20:06:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1S46m4b074628; Fri, 27 Feb 2004 20:06:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1S46kTD074622 for <[e-mail]>; Fri, 27 Feb 2004 20:06:47 -0800 (PST) (envelope-from [e-mail])
Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1Awvkd-0005FM-AK; Fri, 27 Feb 2004 23:06:55 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, <[e-mail]>
Subject: Protocol Action: 'X.509 Extensions for IP Addresses and AS  Identifiers' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Fri, 27 Feb 2004 23:06:55 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'X.509 Extensions for IP Addresses and AS Identifiers '
   <draft-ietf-pkix-x509-ipaddr-as-extn-03.txt> as a Proposed Standard

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

The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary

  This document defines two X.509v3 certificate extensions.  The first
  extension binds a list of IP address blocks, or prefixes, to the
  subject of a certificate.  The second extension binds a list of
  autonomous system identifiers to the subject of a certificate.  These
  extensions may be used to convey the authorization of the subject to
  use the IP addresses and autonomous system identifiers contained in
  the extensions.

Working Group Summary

  The PKIX Working Group came to consensus on this document.  The
  document was also reviewed by the SEND Working Group.

Protocol Quality

  This document was reviewed by Russell Housley for the IESG.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RH59hZ030249; Fri, 27 Feb 2004 09:05:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1RH59qo030248; Fri, 27 Feb 2004 09:05:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RH552P030235 for <[e-mail]>; Fri, 27 Feb 2004 09:05:08 -0800 (PST) (envelope-from [e-mail])
Received: from [10.1.187.100] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1RH51M9004416; Fri, 27 Feb 2004 12:05:02 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06020400bc6525908ec6@[10.1.187.100]>
In-Reply-To: <06fc01c3fc9a$0e336c00$0500a8c0@arport>
References: <06fc01c3fc9a$0e336c00$0500a8c0@arport>
Date: Fri, 27 Feb 2004 12:04:01 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: OMA's signText: No Policy OID
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 19:53 +0100 2/26/04, Anders Rundgren wrote:
>"signText" which is the only on-line signature standard
>there is, which has been defined by the Open Mobile Alliance
>(backed by all the big guys) supports client certificate
>filtering based on CA, but not on Policy OID.
>
>I'm sorry for being such a PITA but it might be of some value
>for implementers of CAs to know that multi-policy PKIs
>(in contrast to having separate CAs each supporting
>a single policy) indeed have some practical issues.
>
>Current multi-policy-CA incompatibility list:
>- Major off-the shelf software (IE, Outlook, IIS)
>- SSL/TLS
>- signText
>- Most trust store management systems
>- Common PKI knowledge level
>- Streamlined administration support
>
>Anders R

Well, it's good to know that even you characterize yourself as a PITA.

The cited examples above are, as I have come to expect, a hodge 
podge.  You may factually cite a specific, non-compliant 
implementation of a specified protocol as evidence in support of your 
notion that we don't need policy OID support, but  the last two 
bullets above merely represent your perception. The claim that 
SSL/TLS do not support policy OIDs is based on an interpretation of 
one feature of these protocols, i.e., their ability to inform a 
client of the CAs that a server is prepared to use in validating 
client certs.  However, the folks who have extensive experience with 
these protocols have made it clear that the reasons for doing this 
are historical, not an architected feature. Then there's your 
"signtext" example, which is just an instance of a vendor consortium 
suggesting something for their environment.  That has all the glitter 
of WAP!

In summary, your argument is more or less:
	- non-compliant implementations do X.
	- some vendors got together and decided to do X explicitly.
	- some protocols are silent on use of X, for historical reasons
	- thus X should be removed from IETF standards

I am not persuaded by an argument of this form.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLOuGc091766; Thu, 26 Feb 2004 13:24:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QLOuBZ091765; Thu, 26 Feb 2004 13:24:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av2-2-sn3.vrr.skanova.net (av2-2-sn3.vrr.skanova.net [81.228.9.108]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QLOtuq091758 for <[e-mail]>; Thu, 26 Feb 2004 13:24:55 -0800 (PST) (envelope-from [e-mail])
Received: by av2-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 1E4667413E; Thu, 26 Feb 2004 21:21:52 +0100 (CET)
Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av2-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 244663C8BD for <[e-mail]>; Thu, 26 Feb 2004 20:04:27 +0100 (CET)
Received: from arport (t8o913p16.telia.com [213.64.26.136]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id D1A95383A0 for <[e-mail]>; Thu, 26 Feb 2004 20:01:19 +0100 (CET)
Message-ID: <06fc01c3fc9a$0e336c00$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: OMA's signText: No Policy OID
Date: Thu, 26 Feb 2004 19:53:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"signText" which is the only on-line signature standard
there is, which has been defined by the Open Mobile Alliance
(backed by all the big guys) supports client certificate
filtering based on CA, but not on Policy OID.

I'm sorry for being such a PITA but it might be of some value
for implementers of CAs to know that multi-policy PKIs
(in contrast to having separate CAs each supporting
a single policy) indeed have some practical issues.

Current multi-policy-CA incompatibility list:
- Major off-the shelf software (IE, Outlook, IIS)
- SSL/TLS
- signText
- Most trust store management systems
- Common PKI knowledge level
- Streamlined administration support

Anders R



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QHPRb5077918; Thu, 26 Feb 2004 09:25:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1QHPQ6R077917; Thu, 26 Feb 2004 09:25:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QHPNJY077896 for <[e-mail]>; Thu, 26 Feb 2004 09:25:26 -0800 (PST) (envelope-from [e-mail])
Received: from [10.1.187.100] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1QHPCMD015848 for <[e-mail]>; Thu, 26 Feb 2004 12:25:20 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06020404bc63dc0fecb5@[10.1.187.100]>
Date: Thu, 26 Feb 2004 12:23:47 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: agenda, from Tim
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PKIX WG (pkix-wg)

Monday March 1, 2001 1530-1730
=================================

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

AGENDA:

1. Document Status Review [Steve Kent]

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

2. PKIX WG Specifications

    2.1  Subject Identification Method   Jongwook Park (KISA)

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

       A new draft of the Subject Identification Method has been submitted.
       This darft is reasonably mature, and should progress out of the WG
       with the next draft. (20 min.)

    2.2 RFC 3280 Progression	TBD

       NIST is currently performing the interoperability testing for RFC 3280.
       This presentation will update the WG on NIST's progress, projected
       completion date, and issues identified to date.  (5 min.)


3. Related Specifications & Liasion Presentations

    TBD



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q0i2XL050379; Wed, 25 Feb 2004 16:44:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1Q0i1h7050378; Wed, 25 Feb 2004 16:44:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q0i0AL050372 for <[e-mail]>; Wed, 25 Feb 2004 16:44:01 -0800 (PST) (envelope-from [e-mail])
Received: from romans (unknown [199.222.124.106]) by smtp1.pacifier.net (Postfix) with ESMTP id 3F1B36EFF2; Wed, 25 Feb 2004 16:44:06 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Jongwook Park'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-02.txt
Date: Wed, 25 Feb 2004 16:48:49 -0800
Message-ID: <!~![e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_006C_01C3FBBF.3E48CE70"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <!~![e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-MS-TNEF-Correlator: 00000000C61F957EEEE3D311963C000086335A6484982F00
Thread-Index: AcP6X/44ZvwviwxqSgC9RQ9LVJGZ6QBMZRGwABpJ5QA=
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_006C_01C3FBBF.3E48CE70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Park,

Thanks for looking at the issues I raised.  I will attempt to further
explain items #12 and #14 here so that you can see what I am talking about.


#12 -- The only reason that I can see for an RA to pass the SII on to the CA
is that the CA wishes to validate that the SII value is correct.  This means
that the CA needs to validate two different pieces of information:  1) the
SII does indeed correspond to a value that Alice is permitted to use and 2)
that the SII is acutally correctly encoded in the PEPSI value and the RA is
not lying to the CA about the SII value that is embeded in the SII.  While
the current syntax allows for test #1 to occur, test #2 cannot occur without
the knowledge of SIIType and Pa.

#14 -- If you look at the syntax for a PKCS#10 item, the EE creates a
signature over the entire request body to be sent up to the CA.  This is
done for reasons of POP.  However if the RA modifies the request body by
placing the new control into the PKCS#10 request, then the POP would break
on the PKCS#10 request.  Thus to work the EE would need to have the PEPSI
and insert the value by itself.

jim 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jongwook Park
Sent: Wednesday, February 25, 2004 5:26 AM
To: [e-mail]
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-sim-02.txt

Jim,

I appreciate for your thorough reviewing of the SIM draft.

To better share my idea with you, I categorized your comments into the
following way :

(1) Major issues :   #1, #16, #19
 Actually, there was a little confusion when I submitted the new draft. The
final draft I submitted was different from the draft posted currently. I
already recognized the problem(#1, #17) you pointed out.  In addition, I
also noticed that the OID for id-on-sim-pepsi is not necessary(#16). Please
refer the attached draft.

For your convenience, I briefly introduce the *NEW* solution.

New solution:   Let SIM = R || PEPSI where
                         PEPSI = H(H( P || R || SIItype || SII))

Then, 

 - In section 2.3, Bob can get R from the SIM in the cert, SIMa. After that,
he can compute PEPSI = H(H(Pa || R || SIItype || SIIa)) and compare it to
the value in SIMa, thereby verifying SIIa.

- In section 2.3, Alice can now send an intermediate value H(Pa || R ||
SIItype || SII) since the R is published in the certificate as a form of SIM
= R || PEPSI.

- Basically, the value of R is salt which it can be published in a
certificate. So Alice doesn't have to remember it. The only value which
Alice should remember is the Password, Pa itself. 

I think that above solution will satisfy the requirements defined in Section
2. and resolve the issues you pointed out.

(2) Minor editorials :  #2, #3, #5, #6, #8, #9, #10, #11, #15, and #21 I
have no problem with accepting your suggestions. especially, I'll add an
unambigouous reference for #10.
In response to above comments, next draft will consider theses issues to be
addressed.

(3) Clarifying the comments needed: #12 and #14 Sorry, but  you lost me
here. Please, give me more detail about those questions.

(4) Further consideration needed: #4 and #10 It obviously seems that there
is contradictionary statments between the security requirement and the usage
of encrypted PEPSI(#4). Also, it is unclear how Alice can protect the data
such as SII and P which passed to the
RA(#18). The solution resovled these issues will be delivered, I believe.   

Finally, three comments, #7, #13, and #20 are remained. :-) In #7, I chose
the 160-bit random number since it is easier way to get it by using the hash
algorithm. 
Next, the following text "Encrypting PEPSI with the public key of CA MUST be
derived from PEPSI along with SII ...." in Section 3.6 will be answering for
the #13.
As for the last comment, I'm sure it will be explained if the intermediate
value of PEPSI, H(H( P || R || SIItype || SII)) replaced by H( P || R ||
SIItype || SII).

Once again, thanks for your reviewing.

Best regards,
Park

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jim Schaad
Sent: Wednesday, February 25, 2004 6:51 AM
To: [e-mail]; IETF-PKIX
Subject: Comments on draft-ietf-pkix-sim-02.txt

I have the following comments in regards to this draft.

1.  Previously noted the problem with verifiers getting the value of R.

2.  Section 2.1:  Alice discloses her SII to the RA, not here PEPSI.  This
is computed by the RA.

3.  Eve is trying to determine an SII not Alice's SSN.

4.  How do you reconcile the requirement "The CA does not learn Alice's SII
or here password" with the encrypted pepsi concept presented further on in
the document.

5.  Section 2.3:  You are overloading the symbol SII.  In one case it
represents the general concept of Alice's sensitive information (section
2.1), in another ir represents SIITYPE || SII.  This is confusing.  I
suggest removing all 'Xa' items from section 2.3.

6.  Section 2.3:  What is a SIMa - this is not previously defined (is now
PEPSI)

7.  Section 3:  I worry about the length of R.  Looking at it and seeing
that it is 160-bits long, I think that somebody is going to say - oh - SHA-1
hash of SIIType || SII (maybe with the password) is a good way of getting
the random number.   On what bases is 160-bits chosen?  (Note that the
attack work load is |P| and is independent of R).

8.  Are you going to register any IANA SII Types with this document for user
convenience?  I.E.  For a USA SSN do I include the hyphens?

9.  "The SII is composed of an alphanumeric string and has a type assigned
as well." --> "The SII is composed of an alphanumeric string.  The SSItype
is an OID which defines the format and scope of the SSI value."

10.  Append to section 3.3.  Selection rule are to include requirements on
minimum lengths of the password, manditory sets of characters to be included
in the password (i.e atleast one upper case, one lower case and one numeric
charcter.)

11.  Section 3.5 - one of SHA-1 or SHA-256 needs to be a MUST (or both)

12.  Section 3.6 - If I am running a CA and I require the CA to validate the
SII, I would also require the CA to validate the PEPSI value.  Otherwise
there is no way for the CA to know that the passed along SII value and the
PEPSI value match in any way.

13.  Section 3.6 - The method of encryption needs to be specified.  Am I to
use CMS here or to actually encrypted the value with the public key of the
CA.  How do I do this if what I am using is DH?  What algorithms (bulk and
public) am I required to support to implement this feature?

14.  Section 3.7 - How do I place a PEPSI into a PKCS#10 request.  If I put
it into the attributes field as an RA, I break the signature cehck on the
certificationRequestInfo field.  This does not work.

15.  Section 3.7 - for CRMF - this item needs to be place d in the regInfo
not the controls field. (as implied by regToken being in the regCtrl arc.)

16.  Section 4.2 - Please give an exmample of where I would use the OID
id-on-sim-pepsi.  This structure is only used for hashing purposes and
therefore does not seem to need to be identified.

17.  Section 4.2 - Is this the field that I am suppose to use to pass the
data from me to the RA?  If so then authorityRandom should be optional.

18.  Section 4.2 - How to I protect the data that I am passing to the RA?

19.  Section 5.  - You have a comment about a relying parting getting an SII
from the RA -- bad news all the way around.

20.  Section 5 - text for example 3 does not may any sense to me.

21.  Section 5 - The following text "  A cryptographically secure hash
function such as SHA-1 and SHA-256 is
   recommended to use for preventing the birthday problem. " does not make
sense to me.  This does not in and of itself prevent the birthday problem  


Jim Schaad





------=_NextPart_000_006C_01C3FBBF.3E48CE70
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+IjEAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQYABwABAAAAAAAAAQOQBgCMFQAAJAAAAAsAAgABAAAAAwAmAAAA
AAALACsAAAAAAAMALgAAAAAAAgExAAEAAAAYAAAAAAAAAMYflX7u49MRljwAAIYzWmQkly8AHgBw
AAEAAAAnAAAAQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1wa2l4LXNpbS0wMi50eHQAAAIBcQABAAAA
IAAAAAHD+l/+OGb8L4sMakoAvUUPS1SRmekATGURsAAaSeUACwABDgAAAAACAQoOAQAAABgAAAAA
AAAAxh+Vfu7j0xGWPAAAhjNaZMKAAAADABQOAQAAAB4AKA4BAAAALQAAADAwMDAwMDAyAWppbXNj
aEBud2xpbmsuY29tAWppbXNjaEBud2xpbmsuY29tAAAAAB4AKQ4BAAAALQAAADAwMDAwMDAyAWpp
bXNjaEBud2xpbmsuY29tAWppbXNjaEBud2xpbmsuY29tAAAAAAIBCRABAAAA1hEAANIRAAAtIgAA
TFpGdU8b/ZYDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUO
UQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFkMzYW
UAumIFC5CsBrLAqiCoQKgFQT4DxuawQgAhAFwBewb2sRC4BnIGEFQHRoZY4gBAEKUAQgSSByC3Cx
FBBkLiAgAQPwbAMgyx8wDrBtBTF0bx5gCHB/H2EFwA7AC1MfkCFRBCAjkw4gHyBuZCMxNCAiIV0f
gHMhwB9gHzF5CGAgbmMDkRQQH4B3JJIgEGEebR9QB0Ae5AbgdXQuxx1KHUQjQi0tIB4AH4DJAiBs
eSAgZWEkUAOgnySDIBAlFh5yA5FSQSGi5wqwBBEfYlNJIBApciRi/R+AQysQBAAkdCyVA/EfcMsr
kSHAdgdAaWQfMB+Afy03K/IukQpQLPIFoRggY38m8CCgHgAtAQeABiItOm5VCeBkLk13IcBkBpBm
LyQRAjArUAiQYweRb2ZNH5BuHnEAwHRpAiA6ySCgMSkrp2RvB5ELgOcBAAmAMHRzcAIgI6AhsXZh
L+Ukg0EusDTALPJw3QSQbSLgDrA4E3UUECNz/jI2Ii9JLQEA0CbgB0ApAf8whSkBCfAFoAEAI6Ai
sR9i+FBFUCvwL+Ujgh9iKwH5LQFubwVAKQAe8ixoJrPvL20kgy0BIWBiCYA9yCvx9SCRVzEwbC8C
H4A8UDChyTRhc3kCMGF4HyAhAOxvdx5UDrBzBUAjQCGi9G9jRPEsRoUUQCURQAKvR0Mg0R9gQWZr
QAB3RICcZGcowTUQK/FUeTnA3yNzHPAnCyPCKHFJNRAk0h8esh8mRXUqkxzgS0NTnyNAFlAi4keR
H3FFRSUAzykxRpE4UQCQZ24fMAhw3SjBdhKBH2I0UWkkIRgg7nEf0QVABuBkKRAhsUMg8yVBNGF1
cCxYMPYtATbAjzKQHmMpNDTjUE9QIJH6SEYQZVFSBpA/VgRhBpC3CJArlFJLYikQC1FjQGP/H3Ey
kAfgBaACMANgAyALgP8sZU62UkVPcz4FVoAg0Ahg+mwjoGIpMU1QKXNbvzDz/zqQIaIzwB0QT4Zd
tDKSIaL/E+BRUD4ZI4ILgBQQACAfU08v9FmRIuAUEGxmJwtqXwdwCuMdhihwZsFPBRBnzwuAB0AF
0AeQc2FKMGbDPR1ERgNhNeBGEDKQci2TCJAAMC1wHuB4QADAZQMQLgdwYy4FsB8QWxtqIiGwOmkv
ajldIE95A6BCZRPgZNBtQDUQSv0CIGczwE1BHPIdRAZgAjCtNeBXCYAykHMu0HlHkPRGZV4QdQrA
KRAOMEeQhQHQMCPgNToyNhDANk0dpWtQIGXBBPBoQFcOwCMQAYAuBaBtHURDHmM14GvYanVu9XVi
arMwwTXgUkU14AhQbQeAdwIwNOEDoGQgMAGAa8gtQQCQbS0wMi4M0HSdHUpKB3AdOyXhcHAwsX8H
MC7xHnIk0VFyBbAIYGf6aCkhdgiQA/AfATUBK7T+TXc0JwtyUFMxIUEFwC4Q+wrAH4BtZHEBADhg
SQIkwpdHkCnyDrBnBbBpejdRf3uzc3F2tFtHAhBF8h7ydylwICA6HUooNhFNYX5qBbEfpTXhIzFH
kCNANv2GkjkdRBDAMNBwoDyRT3P/JCGEEFBiLrACQESBWsEh4L8AkClxJZBdASAQH8BiOfb/WlV9
5CiTWDBnYndDiluIov8z+ANSH1OMtDfgRrA3UkUEdykAIJAl4WwpMVLhMLFvb1DAgbMfYnrgbwJg
IWAo/YZ0NzYgJNI34FtBN1Em0v8goQOgkSAz8DWigQIHQCRRj0ABOVE/Qh81T0lEHmPdLsAtAiB4
MznAcACQP8afMpA0wWfQcMCSwTYpIJD+UESAKVBSIjQhH1MhMQDQ/x9wI6B972iwe4ZawVFQAwDd
PXFlgQJeEAiQZikBW0ENA2BkGtBElCpORVf+KiRBCkA1oicLB8KfxoYyFkwUIH2TPQfwIHx8/z5V
ihEYIIc1pB+klT5kopB8SCimIBzgosKisyvxdPNK0qbkKSkdTAnwR5AdSr8oYJRyFBAw0InSeJAz
R5D+QpJwJQNKMAVAorCOt32i/z31NMAAIEeQfaFLYBDAAYC/UWMfMEeQRMIDkXNxcCbg3z5GpgQc
8KaPsPRhp/Ajc/+vMn/CIuAsVi/1A6Ctoogl/1mRUVEGkEBTsdInC6oPOSX/JRJJ0VNiI6ADkZPC
NXAJgP97Iy/0sF+nWVCRnZE/VDmD/3XALrAuET3XrUJYIYFCHyDfUGI1UkpUony1/UIpUL6h/4f2
L+U1AbzjZ9BrMCWBDeD/fHCzASUSU0G9OzhgvkkgkM5TIcA5NDbCbicFQGIk/yHAGCAHgEMRVzGL
5SjjL/T/w+Q5NC4QXcPIOCuUHPAEEP1ggWRHkLqRZJVl+yAQH2D/C4Bgsh8xJrFiQZ/GINRn0P81
oHMwUvFYlVIBdrQBAQuA/z3EBmCqdiNzN7EG8GJFH6X3k26EazsRTQuABbG5oSGwXwcihhNIAIaR
qvEjcQEj1YbSOIaROYaSMIaShoP7cQEjgzJG8CAQYiNAAJJGf4B0ANA0wAUwHvJ7sx/AZ/dKMEaw
NbFzIJA3wXsCh/PcSSchApTAKsJ1UNAG0P9QsAhgCGAEIJoznYIeY07x/ycFlIE3tDqhODLPE4JW
R5D/MpAO0Yy0IONawQCQBIEfUv8UEFTiH8NTFJSxN7EgYoRr+jM2IEMLYLU2RLN2ljKSvwmANeAj
SsagMKBwMWJBcf9M1UaxB4Aj85mmR5BnQGJB/+xBBGAkIQEAAZADEUFGj7CvH4BSY92jhGs0NiBG
IfX/5MY1k+moI+AjhBZQpzAo0P5ifLDgESkBJVEjES02stL/MGJa4ZEgDeA1onCyRrAfMP92tH8x
VvBdBapRCHGnQND6/z8XOpBn4TTyPXFwwAUwN1H/PmOSwPDAreGVgUeQswEtAf3fgGOZ0QXASTAH
4LfoklH/DrAw0I70HzBQgRrQ3CEGQf8sAUsTw9UrYjo0H2GjtCsAvZLBOJmRKKLPZ9NydkoB/+VE
H5Yg41NBDxAusFFRCYDfncME4VcBIJGpK0ZnUogE8wnR4xkjN4aSqvHaVBZQz3/CyDELcSByOi02
IJSBnwiiKfHvAx9ihsAwLd/Az87gIDAjkI7RbnXIc7xE//wUKUEScoQSIbGrorMBWZF/ibFaFRPg
LhBF0YGC3BBtf81WoRDj4E90g3ghUOPhIn5F+nQe8qMFgJKSE71CYx1JsGVw0DUBLNFNVVP+VASU
+EBRUCOgjrNitevwV4PigJIr8i4YkSLSSjP+LnGwBFYxkVbw+EAfAUZT9x9xCOEnBUFGNR9xWdBG
sf+CVd6iJhAfwLLUBFYiZT3C/1dkuU9KQz5jR5CmL6c8KSH/WcI3UVmRIf+nWWT7bVA5Ye9n4Aoh
T3LEgGtGNHuzfJf/ZPttgEaxB8AngMyA45CjtP9uuGZvZ39oj2vvaq8vH2zP623UZdFTmxBhkSBu
/3APsXEVNjo12rBx2mtJMDl64GlAeAD54DBRLmuEcjuKUEVURi1OsPxJWHVddo93n3iu2tWDPF+C
WSqGU+RVApt/MZRRUP98kvP0mIGR7Bf0tRMOUb8Qv6uh3JPCfGT70wHSeTGGMf/G1YXA/JDvEb8Q
8TL/YlP1/wGQ46GYkfUTwIRUmK81JEPvV4Rk+xmgpJBFYkHLsnDA/1oDDuDuIblxH0G5Av9imIKl
ylMn/0FTTmT7NFakf8ch66ORYvpw7mCfBPiaIv+MEhXBxzKYc/yixZBQt/9x/9bR9RMAYsxiGNAU
V/pol/T/U0LccZJB5XGT04mg8RTS0V+s1ccwkBA68mT7NUdbM92GMVnrwbLC4uFy6/D14flFZXN5
y2CDgP9SlFSdIP+u0gOyKnJaJcvE+gAxQS0h/1mmfTFQtrjBweD2IE5iiZD7v2Hx9CiqWIUw+/HF
kZiBz/Ey+NBhirvxVFmjACUl/0t7iZMpUZRh3SbIIuLgGsLB3mEgJ1hhJ8zh9HLXFvOqWdWbNl1P
V87Cy7H/xbCtoqnxQKOYVXrh89bR1roomFN3KxWjEqgLN0dZv14SFDHrAu6HHLHgoGfcEfNGM6Hx
b288QGtiDyPzAv/0UUVUd+TLsQwFvxAXsoEC/85Z+9C5kO6gkTHLsYGATvU3+eA2UMGgb8owwaBT
SPxBLdqwEEO/o2gwu4hlgP0v0HnmYRRYzDWTQG/D3+D/nsCEA7+hRRWjtFPDDJoGEvczAYoQ9NFi
mfFL03mnC2Pkbj+kkChO/fGWN6O0P5rTzpBXsc6QXxLLonxQ/6Lg8wJLwglAmAC40Y5ywxL1Jkw4
lFFB7fHrsnwnKpGP5cCuIsSANlBJQU4V0P//Yn5yBDIUc0DCW/Ua8+Ag7/FEnUaGAcDARZRRnILF
sP8WAI2RUUBSompgvFECgNHQpw/0u4Co4XM/qBo5YHH/VMP/Ykv17xHVQR+gxIEQkP+TYMSAXBH4
QBUwHPAas/MC/xBBxaGnQwBx39ByMv8x93D3GgAYwSxwPpS/lc+W20tzH6xxpdCnQ2/CxZBPSUT/
w9XR1MvEZPR4NB0gu5G/oX+sU6XRuhMYwEFb4VBIQXD/iaJ8cxk3ThLSgPyg0qQ2EP9TkbLCDtGS
htEL0tFPsTyQ/w0AdnU7MR+kV3YnwC/QCUD/1yL0MjsiH6A0IQyA0qBE0l/mNJKFvbdXdnJhLhpB
dPfs4vORT9F1ovHxUe0DYNL/EnGuVQkjYNKWxdYEqnKqws4uc5vZwHR6LjV84k/R/7+ifXPW0X1i
NnAZwOmy5hf9FeQo1tHuoNwQsbxHShmivcGgSR+g/4Hb0DYQbpBg/2tiFbLzAmpgVAXT4xXBDtH/
INHlACCSoOMjgAsiV7DK4v/XccgSur+7yhP0oWSD4fUCf9vwC5T1NNtBgXIbBr5ka/9ysYaHAFYX
pH7yINT5Vr+Z/alBdMohZoM2UIFxQUykJP+4KgIiIFDu8ZtD+mXyFuYW/94TRLEKYVYg29BJw4/B
6CD8TVNKxBsS4qHSoDYg3nH/+llFmBRfFWS+JFJIamBSsT9whB+ghDO5Ew+kTpFESK+GAW9zEJeA
4CjrYGx68P/zAeeUFOSAsLkxunejNK4h/1bw9OGloUxA27GJ4kCj4HDf9NAeAZO76sCyqzd9MdIX
PyPzgPET9CAB4qHswEtD/lPzQlQCKlFgcrjyTFF5M//d4hySh3H4QOthSTHMIb0i753zSlIFgQfA
YXryAkGY0f/aE6pgM0CHsWXx6OPAoPYg98wg/ZD2IlLe1ArQGwDhVH9LdlVHh+JBTF063AQbAkP4
Uk1GcFdsMbUr3PSr9/8qkeXTcQLkU/WiAnDhRWBw/ij/MdkCzDEkUiqRN9AVUO+boBow1BPsZ0NO
wBoQsUHXsa1uWlIwMn0xUK2CYmH/ZJL9oRGwL9DZEhWCnoBK4t+81s0SHJKeQr7wLZAgPHP/WUNL
dpdB/vDjc06RkCBC0b+PwRbRVvIQURrCTFBymwL/nfJDQwfAGwFbwlVleIFEAP8O0bUyqxaJ0swU
QVt0avN0/kmfQk6SPmLhc3jzuRPYU/8Lksz0DtGsgluUxpCBABbz/yBQSdiQwh+gvXEckZuhTGDz
C3AQ0XlSDJQQYL0DGjH/ODBtAhCQQUyLQvL8UnIO0f/c0UOwhmBlwAO4Abisgk71/wUFQVuUgkeG
XTK4wF5SPgP/gQAdJXXVgQD7wHHA+oMsMP8To0UWUAUW80oUmcGEcazw/TFAd4DhGgEckoFyLDBx
kP+6QEZ8oqIO13BSHvCPZB7w/fT0M1U4f0GNE2QypXMgUP9GfLKas3JU0j6YF9NX8FYg86pgypJv
Z4Lwk2Dk8c6S/2zR44J9w1rAWLBtA2qAnrH/mAF9ZLoytLaMwCwUg9FTIv8/UqvSzOXCEnFC/hJF
ZYVQ/1rhNZFDlmBwHdAZCdEQGgv/5o5mg5tDefGZcKhQJFUk/31D0yA9KkG0M94t3z11fQEvwAAA
AgEUOgEAAAAQAAAAJtxcoIgXgEmG5gIZkrPUXAMA3j+fTgAAAwAJWQEAAAADAACACCAGAAAAAADA
AAAAAAAARgAAAAAQhQAAAAAAAAsABYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwAGgAgg
BgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAAeACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAA
AAsACIAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAA
GIUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsAHw4BAAAAAgH4DwEAAAAQ
AAAAxh+Vfu7j0xGWPAAAhjNaZAIB+g8BAAAAEAAAAMYflX7u49MRljwAAIYzWmQDAP4PBQAAAAMA
DTT9PwMAAwAPNP0/AwACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAw
MDAwMDBDNjFGOTU3RUVFRTNEMzExOTYzQzAwMDA4NjMzNUE2NDg0OTgyRjAwAAAAAAMABhBnHKFz
AwAHEPIXAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAUEFSSyxUSEFOS1NGT1JMT09LSU5H
QVRUSEVJU1NVRVNJUkFJU0VESVdJTExBVFRFTVBUVE9GVVJUSEVSRVhQTEFJTklURU1TIzEyQU5E
IzE0SEVSRVNPVEhBVFlPVUNBTlNFRQAAAADgZg==

------=_NextPart_000_006C_01C3FBBF.3E48CE70--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PHOqnD019667; Wed, 25 Feb 2004 09:24:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PHOqHX019666; Wed, 25 Feb 2004 09:24:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from besec550.swift.com (mta1.swift.com [195.99.94.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PHOoZg019656 for <[e-mail]>; Wed, 25 Feb 2004 09:24:50 -0800 (PST) (envelope-from [e-mail])
Received: by besec550.swift.com  with ESMTP id i1PHMbFd018256 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for <[e-mail]>; Wed, 25 Feb 2004 17:22:38 GMT
Received: (from root@localhost) by besec550.swift.com (Switch-3.1.4/Switch-3.1.0/Submit) id i1PHMbfM018254; Wed, 25 Feb 2004 17:22:37 GMT
Received: from mail2.swift.com ([172.24.88.9]) by besec511; Wed, 18 Feb 2004 13:31:31 +0000 (GMT)
Received: by besec550.swift.com  with SMTP id i1IDUal6013861 for <[e-mail]>; Wed, 18 Feb 2004 13:30:37 GMT
X-Proxy: hello
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IBfRZ3029140; Wed, 18 Feb 2004 03:41:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1IBfR6T029139; Wed, 18 Feb 2004 03:41:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IBfPAK029109 for <[e-mail]>; Wed, 18 Feb 2004 03:41:25 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (csmail.cs.auckland.ac.nz [130.216.33.150]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 80F1F3419B for <[e-mail]>; Thu, 19 Feb 2004 00:39:32 +1300 (NZDT)
Received: from 218-101-44-120.paradise.net.nz (218-101-44-120.paradise.net.nz [218.101.44.120]) by mail.cs.auckland.ac.nz (Horde) with HTTP for <[e-mail]>; Thu, 19 Feb 2004 00:41:20 +1300
Message-ID: <[e-mail]>
Date: Thu, 19 Feb 2004 00:41:20 +1300
From: Peter Gutmann <[e-mail]>
To: [e-mail]
Subject: RE: No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MASF: 0.0
X-MASF: 0.00%
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>So Anders' statement that "TLS and SSL which are very popular security
>protocols do not support client certificate filtering using policy OIDs" is
>incorrect.

It's not incorrect, it's correct in that the protocol doesn't care what you do
with OIDs (or policies).  Your cert validation engine can do what it wants,
but all the TLS protocol itself cares about is a bUseThisCert flag.  The only
thing you can specify in TLS is the CA name, and even that's frequently left
empty (see the note in the RFC) because the server is in a better position to
know which certs it'll accept than the user, and matching certs by DN is
better done by the server software than by presenting the user with a dialog
asking for a cert with the following issuer DN.

>It may be the case that one or more popular implementations of TLS/SSL do not
>support such certificate filtering, but that's not the same as the protocol
>not supporting it.

Actually the protocol really doesn't support it - there's nothing in the TLS
protocol that allows you to specify any kind of cert policy information.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFcibd012270; Wed, 25 Feb 2004 07:38:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PFciZL012269; Wed, 25 Feb 2004 07:38:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from besec550.swift.com (mta1.swift.com [195.99.94.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFcgSJ012259 for <[e-mail]>; Wed, 25 Feb 2004 07:38:43 -0800 (PST) (envelope-from [e-mail])
Received: by besec550.swift.com  with ESMTP id i1PFaa9Z005239 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 25 Feb 2004 15:36:37 GMT
Received: (from root@localhost) by besec550.swift.com (Switch-3.1.4/Switch-3.1.0/Submit) id i1PFaaHi005236; Wed, 25 Feb 2004 15:36:36 GMT
Received: from mail2.swift.com ([172.24.88.9]) by besec510; Wed, 18 Feb 2004 00:11:26 +0000 (GMT)
Received: by besec550.swift.com  with SMTP id i1I0DTaf005521 for <[e-mail]>; Wed, 18 Feb 2004 00:13:30 GMT
X-Proxy: hello
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HGi0i4088464; Tue, 17 Feb 2004 08:44:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1HGi0W6088463; Tue, 17 Feb 2004 08:44:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HGhx8k088457 for <[e-mail]>; Tue, 17 Feb 2004 08:43:59 -0800 (PST) (envelope-from [e-mail])
Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 5350171F0; Tue, 17 Feb 2004 08:44:00 -0800 (PST)
Received: by romeo.rtfm.com (Postfix, from userid 556) id 6E84044ABD; Tue, 17 Feb 2004 08:44:00 -0800 (PST)
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "David Cross" <[e-mail]>
Subject: Re: TLS:  No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
References: <[e-mail]> <p06020405bc5684baadc0@[128.89.89.75]> <001c01c3f4bb$8429a7d0$0500a8c0@arport> <005601c3f52b$77192000$0500a8c0@arport> <[e-mail]> <01e401c3f570$70f4a790$0500a8c0@arport>
Reply-To: EKR <[e-mail]>
From: Eric Rescorla <[e-mail]>
Date: 17 Feb 2004 08:44:00 -0800
In-Reply-To: <01e401c3f570$70f4a790$0500a8c0@arport>
Message-ID: <[e-mail]>
Lines: 20
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MASF: 0.0
X-MASF: 0.00%
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Anders Rundgren" <[e-mail]> writes:
> "The part of TLS that governs what certificates a client will try to use for
> authenticate is the ClientCertificateRequest message.  That message
> can only contain requests on certificate types and issuer DNs"
> 
> This is what we are talking about.

Ok. that wasn't entirely  clear from your message.


> BTW, why didn't you include policy OIDs?

TLS is a lineal descendent of SSL, which predates PKIX by quite some
time. The certificate request syntax in SSL didn't contain any support
for auxiliary information and it just never got added to TLS.
Remember that TLS client authentication is a fairly unwidely used
feature in any case.

-Ekr



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFcIIW012239; Wed, 25 Feb 2004 07:38:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PFcIbM012238; Wed, 25 Feb 2004 07:38:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from besec550.swift.com (mta1.swift.com [195.99.94.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFcGMe012222 for <[e-mail]>; Wed, 25 Feb 2004 07:38:17 -0800 (PST) (envelope-from [e-mail])
Received: by besec550.swift.com  with ESMTP id i1PFZjps005126 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 25 Feb 2004 15:35:46 GMT
Received: (from root@localhost) by besec550.swift.com (Switch-3.1.4/Switch-3.1.0/Submit) id i1PFZfwM005123; Wed, 25 Feb 2004 15:35:41 GMT
Received: from mail2.swift.com ([172.24.88.9]) by besec511; Tue, 17 Feb 2004 23:31:56 +0000 (GMT)
Received: by besec550.swift.com  with SMTP id i1HNUxQS002302 for <[e-mail]>; Tue, 17 Feb 2004 23:31:00 GMT
X-Proxy: hello
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HFBssd082907; Tue, 17 Feb 2004 07:11:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1HFBsbI082906; Tue, 17 Feb 2004 07:11:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HFBorv082898 for <[e-mail]>; Tue, 17 Feb 2004 07:11:51 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Tue, 17 Feb 2004 16:11:22 +0100
Date: Tue, 17 Feb 2004 16:11:22 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: No policy OID. Was: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <005601c3f52b$77192000$0500a8c0@arport> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MASF: 0.0
X-MASF: 0.00%
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Tue, 17 Feb 2004 08:16:29 -0500, "Al Arsenault" <[e-mail]> said:

aarsenau> Actually, RFC 2246, TLS 1.0 protocol spec, says:
aarsenau> 
aarsenau>  All certificate profiles, key and cryptographic formats are defined
aarsenau>    by the IETF PKIX working group [PKIX].
aarsenau> 
aarsenau> (That's in section 7.4.2, towards the bottom of page 38.)
aarsenau> The reference, [PKIX], points to RFC 2459.
aarsenau> 
aarsenau> In this area, then, TLS supports what PKIX supports.
aarsenau> 
aarsenau> So Anders' statement that "TLS and SSL which are very
aarsenau> popular security protocols do not support client certificate
aarsenau> filtering using policy OIDs" is incorrect.  It may be the
aarsenau> case that one or more popular implementations of TLS/SSL do
aarsenau> not support such certificate filtering, but that's not the
aarsenau> same as the protocol not supporting it.

Uhmm, I think you misunderstood what Anders asked about.  The part of
TLS that governs what certificates a client will try to use for
authenticate is the ClientCertificateRequest message.  That message
can only contain requests on certificate types and issuer DNs.  The
way I understand what Anders asks for, he complains about the absence
of policy OIDs in that message, thereby indicating to the client what
policies are accepted, and thereby limiting the choice of certificates
that is presented to the user of said client software, perhaps even
down to 1 certificate.

Anders asserts the absence of anything policy-related in
ClientCertificateRequest is yet another proof that multi-policy CAs
are just awkward.

Seen from Anders' point of view (as I understand it, it's about
minimising the amount of stuff a user has to keep track of), I
perfectly undrstand what he talks about.  I don't share his view,
though.  My view is that if a user has enough trust to be handed more
than certificate, he should have enough knowledge to use them
properly.  The flaw really lies in client software that currently do
not show policy information in any kind of way (uhmm, except if you
choose to look at a complete view of the certificate in question,
where you must search manually for the policy extensions and know how
to extract the data you need from them).  Client software could show
the policies associated with each certificate, perhaps with some
friendly name, to make it easier for the user to make an appropriate
choice.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFbfgD012200; Wed, 25 Feb 2004 07:37:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PFbfap012199; Wed, 25 Feb 2004 07:37:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from besec550.swift.com (mta1.swift.com [195.99.94.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFbdqb012193 for <[e-mail]>; Wed, 25 Feb 2004 07:37:39 -0800 (PST) (envelope-from [e-mail])
Received: by besec550.swift.com  with ESMTP id i1PFZWbI005118 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 25 Feb 2004 15:35:33 GMT
Received: (from root@localhost) by besec550.swift.com (Switch-3.1.4/Switch-3.1.0/Submit) id i1PFZWc2005112; Wed, 25 Feb 2004 15:35:32 GMT
Received: from mail2.swift.com ([172.24.88.9]) by besec510; Tue, 17 Feb 2004 23:28:56 +0000 (GMT)
Received: by besec550.swift.com  with SMTP id i1HNUxFP002303 for <[e-mail]>; Tue, 17 Feb 2004 23:31:00 GMT
X-Proxy: hello
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HH48vp089809; Tue, 17 Feb 2004 09:04:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1HH48of089808; Tue, 17 Feb 2004 09:04:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-1-sn1.fre.skanova.net (av1-1-sn1.fre.skanova.net [81.228.11.107]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HH47kG089799 for <[e-mail]>; Tue, 17 Feb 2004 09:04:07 -0800 (PST) (envelope-from [e-mail])
Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id 4A02A37E5E; Tue, 17 Feb 2004 18:04:03 +0100 (CET)
Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id 3D7DA37E59 for <[e-mail]>; Tue, 17 Feb 2004 18:04:03 +0100 (CET)
Received: from arport (t11o913p8.telia.com [213.64.28.8]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id E3FB237E43; Tue, 17 Feb 2004 18:04:01 +0100 (CET)
Message-ID: <028701c3f577$34cc1850$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "EKR" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "David Cross" <[e-mail]>
References: <[e-mail]><p06020405bc5684baadc0@[128.89.89.75]><001c01c3f4bb$8429a7d0$0500a8c0@arport><005601c3f52b$77192000$0500a8c0@arport><[e-mail]><01e401c3f570$70f4a790$0500a8c0@arport> <[e-mail]>
Subject: Re: TLS:  No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Date: Tue, 17 Feb 2004 17:58:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MASF: 0.0
X-MASF: 0.00%
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric,

>> BTW, why didn't you include policy OIDs?

>TLS is a lineal descendent of SSL, which predates PKIX by quite some
>time. The certificate request syntax in SSL didn't contain any support
>for auxiliary information and it just never got added to TLS.

I sort of guessed that.

>Remember that TLS client authentication is a fairly unwidely
>used feature in any case.

I believe the full message is rather that client certificates are still
uncommon.

This will however change but it is possible that TLS' client-auth
will not be used as most of the systems I have seen, rather use Java
applets for authentication.  This is due to the fact that the client-side
PKI in browsers is generally not that useful anyway, as browsers
cannot sign web content. 

It really looks like client-side PKI is still in its infancy.

Anders



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFZNbY012134; Wed, 25 Feb 2004 07:35:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PFZNcq012133; Wed, 25 Feb 2004 07:35:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from besec550.swift.com (mta1.swift.com [195.99.94.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFZLrw012124 for <[e-mail]>; Wed, 25 Feb 2004 07:35:22 -0800 (PST) (envelope-from [e-mail])
Received: by besec550.swift.com  with ESMTP id i1PFXFg0004728 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 25 Feb 2004 15:33:16 GMT
Received: (from root@localhost) by besec550.swift.com (Switch-3.1.4/Switch-3.1.0/Submit) id i1PFXDfw004724; Wed, 25 Feb 2004 15:33:13 GMT
Received: from mail2.swift.com ([172.24.88.9]) by besec511; Tue, 17 Feb 2004 21:55:37 +0000 (GMT)
Received: by besec550.swift.com  with SMTP id i1HLsfhd024312 for <[e-mail]>; Tue, 17 Feb 2004 21:54:42 GMT
X-Proxy: hello
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HGFhVU086778; Tue, 17 Feb 2004 08:15:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1HGFhV0086777; Tue, 17 Feb 2004 08:15:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av9-2-sn1.fre.skanova.net (av9-2-sn1.fre.skanova.net [81.228.11.116]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HGFgeE086762 for <[e-mail]>; Tue, 17 Feb 2004 08:15:42 -0800 (PST) (envelope-from [e-mail])
Received: by av9-2-sn1.fre.skanova.net (Postfix, from userid 502) id D0F9F37E57; Tue, 17 Feb 2004 17:15:37 +0100 (CET)
Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av9-2-sn1.fre.skanova.net (Postfix) with ESMTP id C4B6C37E45 for <[e-mail]>; Tue, 17 Feb 2004 17:15:37 +0100 (CET)
Received: from arport (t7o913p43.telia.com [213.64.26.43]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 64D3E37E4C; Tue, 17 Feb 2004 17:15:35 +0100 (CET)
Message-ID: <01e401c3f570$70f4a790$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "EKR" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "David Cross" <[e-mail]>
References: <[e-mail]><p06020405bc5684baadc0@[128.89.89.75]><001c01c3f4bb$8429a7d0$0500a8c0@arport><005601c3f52b$77192000$0500a8c0@arport> <[e-mail]>
Subject: Re: TLS:  No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Date: Tue, 17 Feb 2004 17:09:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MASF: 0.0
X-MASF: 0.00%
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric.
Richard Levitte wrote:

"The part of TLS that governs what certificates a client will try to use for
authenticate is the ClientCertificateRequest message.  That message
can only contain requests on certificate types and issuer DNs"

This is what we are talking about.

BTW, why didn't you include policy OIDs?

Anders

----- Original Message -----
From: "Eric Rescorla" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "Santosh Chokhani" <[e-mail]>; "David Cross"
<[e-mail]>
Sent: Tuesday, February 17, 2004 16:57
Subject: Re: TLS: No policy OID. Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)


"Anders Rundgren" <[e-mail]> writes:

> http://www.ietf.org/rfc/rfc2246
>
> TLS and SSL which are very popular security protocols
> do not support client certificate filtering using policy OIDs.

Actually, TLS is totally agnostic on this front, since it just
incorporated PKIX by reference. It's true that I don't
know of any TLS implementation that makes this easy
(though you can generally extract the cert and check for
yourself).

What doesn't work is that there's no way for peer A to signal
peer B that it wants a specific policy. Is that what you're
talking about?

-Ekr



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFYEqj012075; Wed, 25 Feb 2004 07:34:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PFYEik012074; Wed, 25 Feb 2004 07:34:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from besec550.swift.com (mta1.swift.com [195.99.94.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFYDxE012066 for <[e-mail]>; Wed, 25 Feb 2004 07:34:14 -0800 (PST) (envelope-from [e-mail])
Received: by besec550.swift.com  with ESMTP id i1PFW8sJ004600 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for <[e-mail]>; Wed, 25 Feb 2004 15:32:09 GMT
Received: (from root@localhost) by besec550.swift.com (Switch-3.1.4/Switch-3.1.0/Submit) id i1PFW8ID004598; Wed, 25 Feb 2004 15:32:08 GMT
Received: from mail2.swift.com ([172.24.88.9]) by besec510; Tue, 17 Feb 2004 21:27:28 +0000 (GMT)
Received: by besec550.swift.com  with SMTP id i1HLTXkE021964 for <[e-mail]>; Tue, 17 Feb 2004 21:29:34 GMT
X-Proxy: hello
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HIaSGs004592; Tue, 17 Feb 2004 10:36:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1HIaSUu004591; Tue, 17 Feb 2004 10:36:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HIaR5G004584 for <[e-mail]>; Tue, 17 Feb 2004 10:36:28 -0800 (PST) (envelope-from [e-mail])
Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 35809305 for [e-mail]; Tue, 17 Feb 2004 12:33:37 -0600
Date: Tue, 17 Feb 2004 12:36:24 -0600 (CST)
From: Eric Norman <[e-mail]>
To: PKIX list <[e-mail]>
Subject: Re: TLS:  No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
In-Reply-To: <005601c3f52b$77192000$0500a8c0@arport>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: MULTIPART/signed; BOUNDARY="-2140662931-2103392603-1077042988=:17744"; protocol="application/x-pkcs7-signature"; micalg=sha1
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MASF: 0.0
X-MASF: 0.00%
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [e-mail] for more info.

---2140662931-2103392603-1077042988=:17744
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 17 Feb 2004, Anders Rundgren wrote:

> http://www.ietf.org/rfc/rfc2246
>
> TLS and SSL which are very popular security protocols
> do not support client certificate filtering using policy OIDs.

But they do.  Well somewhat at least.

The give you the ability to say in the client certificate request,
"please send me a certificate that has one of these CAs in the chain".
If you adopt the policy = CA notion, this provides what you seem to
be asking for (like I said, somewhat).


Eric Norman

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

---2140662931-2103392603-1077042988=:17744
Content-Type: APPLICATION/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: BASE64
Content-Description: S/MIME Cryptographic Signature
Content-Disposition: attachment; filename="smime.p7s"

MIIIUwYJKoZIhvcNAQcCoIIIRDCCCEACAQExCzAJBgUrDgMCGgUAMAsGCSqG
SIb3DQEHAaCCBkMwggLDMIICLKADAgECAgIDMzANBgkqhkiG9w0BAQQFADCB
tzELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH
TWFkaXNvbjEoMCYGA1UEChMfVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4tTWFk
aXNvbjErMCkGA1UECxMiRGl2aXNpb24gb2YgSW5mb3JtYXRpb24gVGVjaG5v
bG9neTErMCkGA1UEAxMiVVcxLTIwMDMxMjE4IE1pZGRsZXdhcmUgVGVzdGlu
ZyBDQTAeFw0wMzEyMTkwNDA5NDhaFw0wNzA0MDMwNDA5NDhaMIHHMQswCQYD
VQQGEwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29u
MSgwJgYDVQQKEx9Vbml2ZXJzaXR5IG9mIFdpc2NvbnNpbi1NYWRpc29uMSsw
KQYDVQQLEyJEaXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MRQw
EgYDVQQDEwtFcmljIE5vcm1hbjElMCMGCSqGSIb3DQEJARYWZWpub3JtYW5A
ZG9pdC53aXNjLmVkdTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCn/bvHyy3Q
Y9FS6XDkAg45q6w69bD38HdbhdFWvGyTdh+faNbgr5hqtAq/iuNclvgFEiU8
YHPHgqFVrS6Zy/WtAgMBAAGjEDAOMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN
AQEEBQADgYEAD/et82CA8VFuVky/tS586vEbEr1CRkBQvBuluhhUKimFFQz/
9pG4Y7iz+/9zJID3UYuMuXyCI9ZbtncmQgTUK/4bfJwzzdiC2W7XKEHbr8kG
8LSODiGX5zWDW/fZFH4T6kRJt9IhigqgkoFfZYSWbQgGUukOtEv6ZSEmZxYz
PHUwggN4MIICYKADAgECAgInJjANBgkqhkiG9w0BAQQFADCBtDELMAkGA1UE
BhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMHTWFkaXNvbjEo
MCYGA1UEChMfVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4tTWFkaXNvbjErMCkG
A1UECxMiRGl2aXNpb24gb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neTEoMCYG
A1UEAxMfVVcwLTIwMDMxMjAyIE1hc3RlciBDZXJ0aWZpY2F0ZTAeFw0wMzEy
MTgxOTQyMjNaFw0xNDAxMjcxOTQyMjNaMIG3MQswCQYDVQQGEwJVUzESMBAG
A1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSgwJgYDVQQKEx9V
bml2ZXJzaXR5IG9mIFdpc2NvbnNpbi1NYWRpc29uMSswKQYDVQQLEyJEaXZp
c2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSswKQYDVQQDEyJVVzEt
MjAwMzEyMTggTWlkZGxld2FyZSBUZXN0aW5nIENBMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCgfNev1PLA1ThZt61tML6WpjwEyBXneeWARKJq17tC
ji9NS4+3el1bI0HyyGLx2AyvhGH8lFqI9su15epfR7tLfRIT4A3KDDhDdLDF
pvvZArLjw5LODrRrMH+5x3OTcB4zUDx33csKGpNtTUIGDPrFPEKY5PvQLe2t
7KMn13yHIwIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEB
BAUAA4IBAQBZnctVPyoBmuDqHICxf5cejxjAe42enzhImvsJhVQp55chwyyN
VYEKvvbrHFcZGrijDc1CcPLHmC+0+MLCUlkttlW5Hpzs/BSfmm1RXNYxZa2E
gGnr7saJqCNVC7veBXf/Hu1ZJfkyRCO0vO9bD8/m5Zftk2ts4rVNIB8lM0DL
nhH/APVo7NJtNwyBIPomXOc4fCbUzyvSIN/IQJ5HC3iP472TGHXUWYAQKxd4
/A9psV49vjLXQXS9QdF0GiAgp7+COQQU7gMHvIILxMdIZAfyMghAdCBtB5Gt
t9nI9wwO0tEyPWtMclkpRd4MfvD/VnnUnZ4k9P3U/8EOXaHz+G4EMYIB2DCC
AdQCAQEwgb4wgbcxCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNjb25zaW4x
EDAOBgNVBAcTB01hZGlzb24xKDAmBgNVBAoTH1VuaXZlcnNpdHkgb2YgV2lz
Y29uc2luLU1hZGlzb24xKzApBgNVBAsTIkRpdmlzaW9uIG9mIEluZm9ybWF0
aW9uIFRlY2hub2xvZ3kxKzApBgNVBAMTIlVXMS0yMDAzMTIxOCBNaWRkbGV3
YXJlIFRlc3RpbmcgQ0ECAgMzMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwMjE3MTgzNjI3WjAj
BgkqhkiG9w0BCQQxFgQUnJ7YC50Rk4PHcHe4OnZrrGdwqRIwUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN
AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAE
QDnuxwhl9XEtK29YL1D88v+poiVu4jLST2H6iVs8aYgCgc+4pwn3fbOKLMeB
ecDTsbCqrqZTqprbSzognLNm3RY=
---2140662931-2103392603-1077042988=:17744--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFQAp4011102; Wed, 25 Feb 2004 07:26:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PFQ9hq011101; Wed, 25 Feb 2004 07:26:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from besec550.swift.com (mta1.swift.com [195.99.94.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFQ8IY011093 for <[e-mail]>; Wed, 25 Feb 2004 07:26:08 -0800 (PST) (envelope-from [e-mail])
Received: by besec550.swift.com  with ESMTP id i1PFNnms002961 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 25 Feb 2004 15:23:50 GMT
Received: (from root@localhost) by besec550.swift.com (Switch-3.1.4/Switch-3.1.0/Submit) id i1PFNfLg002951; Wed, 25 Feb 2004 15:23:41 GMT
Received: from mail2.swift.com ([172.24.88.9]) by besec511; Tue, 17 Feb 2004 17:05:12 +0000 (GMT)
Received: by besec550.swift.com  with SMTP id i1HH4G2p029250 for <[e-mail]>; Tue, 17 Feb 2004 17:04:17 GMT
X-Proxy: hello
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HEUAqZ080960; Tue, 17 Feb 2004 06:30:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1HEUAoL080959; Tue, 17 Feb 2004 06:30:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HEU6Tq080953 for <[e-mail]>; Tue, 17 Feb 2004 06:30:07 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Tue, 17 Feb 2004 15:29:32 +0100
Date: Tue, 17 Feb 2004 15:29:29 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: TLS: No policy OID. Was: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MASF: 0.0
X-MASF: 0.00%
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Wed, 18 Feb 2004 01:21:00 +1300, Peter Gutmann <[e-mail]> said:

pgut001> 
pgut001> Richard Levitte - VMS Whacker <[e-mail]> writes:
pgut001> 
pgut001> >I choose to develop for tomorrow.  You?
pgut001> 
pgut001> I choose to develop for what the market wants

And quite often, "the market" looks at what's available today and
tries to use that to solve their problems.  It's the same problem as
the old chicken-and-the-egg question: what comes first [1]?

pgut001> (with, admittedly, some attempt at speculating about what
pgut001> it'll want tomorrow, and to counterbalance that a refusal to
pgut001> develop crap if that's what people are asking for).  Seems to
pgut001> be working OK, I haven't had to change jobs once in the last
pgut001> 12 years.

Good for you :-).

-----
[1] my wife told me the real answer: the rooster!

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFPa91011074; Wed, 25 Feb 2004 07:25:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PFPaQV011073; Wed, 25 Feb 2004 07:25:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from besec550.swift.com (mta1.swift.com [195.99.94.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PFPXf5011061 for <[e-mail]>; Wed, 25 Feb 2004 07:25:34 -0800 (PST) (envelope-from [e-mail])
Received: by besec550.swift.com  with ESMTP id i1PFNOal002899 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 25 Feb 2004 15:23:25 GMT
Received: (from root@localhost) by besec550.swift.com (Switch-3.1.4/Switch-3.1.0/Submit) id i1PFNNbo002890; Wed, 25 Feb 2004 15:23:23 GMT
Received: from mail2.swift.com ([172.24.88.9]) by besec510; Tue, 17 Feb 2004 17:10:26 +0000 (GMT)
Received: by besec550.swift.com  with SMTP id i1HHCUHG000034 for <[e-mail]>; Tue, 17 Feb 2004 17:12:30 GMT
X-Proxy: hello
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HEgTs5081607; Tue, 17 Feb 2004 06:42:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1HEgTER081606; Tue, 17 Feb 2004 06:42:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1HEgSJb081595 for <[e-mail]>; Tue, 17 Feb 2004 06:42:28 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1HEgMMB009077; Tue, 17 Feb 2004 09:42:23 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020402bc57d5f8b880@[128.89.89.75]>
In-Reply-To: <005601c3f52b$77192000$0500a8c0@arport>
References: <[e-mail]> <p06020405bc5684baadc0@[128.89.89.75]> <001c01c3f4bb$8429a7d0$0500a8c0@arport> <005601c3f52b$77192000$0500a8c0@arport>
Date: Tue, 17 Feb 2004 09:37:30 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: TLS:  No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Cc: <[e-mail]>, <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "David Cross" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-MASF: 0.0
X-MASF: 0.00%
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:55 +0100 2/17/04, Anders Rundgren wrote:
>http://www.ietf.org/rfc/rfc2246
>
>TLS and SSL which are very popular security protocols
>do not support client certificate filtering using policy OIDs.
>
>And what does that mean?

SSL is an "industry standard," a polite way of saying that one vendor 
created it in a closed context and other vendors copied that 
implementation in an effort to capitalize on an extent market. SSL, 
as published in an IETF Informational RFC, doesn't even discuss how 
to process certs, only to convey them.
Cert processing is a matter covered under HTTPS, which was not 
addressed by any standards document until fairly recently. So, is 
this yet another example from you of "products implementing protocol 
Y don't do X, so X can't be important?" Products implementing SSL 
also didn't do any form of cert status checking for years. Did that 
mean that such checking was unimportant?

Anders, when are you going to realize that working backwards from 
what IS available in products is a bad way to determine what SHOULD 
be available.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PDQCHk002611; Wed, 25 Feb 2004 05:26:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1PDQBxB002608; Wed, 25 Feb 2004 05:26:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from center.kisa.or.kr ([211.252.150.11]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PDQ8bX002600 for <[e-mail]>; Wed, 25 Feb 2004 05:26:09 -0800 (PST) (envelope-from [e-mail])
Received: from khoprivaio (localhost [127.0.0.1]) by center.kisa.or.kr (8.11.7p1+Sun/8.11.1) with ESMTP id i1PDIuI05059; Wed, 25 Feb 2004 22:18:56 +0900 (KST)
From: "Jongwook Park" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-sim-02.txt
Date: Wed, 25 Feb 2004 22:26:03 +0900
Message-ID: <!~![e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EF_01C3FBEE.5BEA8430"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <!~![e-mail]>
Thread-Index: AcP6X/44ZvwviwxqSgC9RQ9LVJGZ6QBMZRGw
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00EF_01C3FBEE.5BEA8430
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Jim,

I appreciate for your thorough reviewing of the SIM draft.

To better share my idea with you, I categorized your comments into the
following way :

(1) Major issues :   #1, #16, #19
 Actually, there was a little confusion when I submitted the new draft. The
final draft I submitted was different from the draft posted currently. I
already recognized the problem(#1, #17) you pointed out.  In addition, I
also noticed that the OID for id-on-sim-pepsi is not necessary(#16). Please
refer the attached draft.

For your convenience, I briefly introduce the *NEW* solution.

New solution:   Let SIM = R || PEPSI where
                         PEPSI = H(H( P || R || SIItype || SII))

Then, 

 - In section 2.3, Bob can get R from the SIM in the cert, SIMa. After that,
he can compute PEPSI = H(H(Pa || R || SIItype || SIIa)) and compare it to
the value in SIMa, thereby verifying SIIa.

- In section 2.3, Alice can now send an intermediate value H(Pa || R ||
SIItype || SII) since the R is published in the certificate as a form of SIM
= R || PEPSI.

- Basically, the value of R is salt which it can be published in a
certificate. So Alice doesn't have to remember it. The only value which
Alice should remember is the Password, Pa itself. 

I think that above solution will satisfy the requirements defined in Section
2. and resolve the issues you pointed out.

(2) Minor editorials :  #2, #3, #5, #6, #8, #9, #10, #11, #15, and #21
I have no problem with accepting your suggestions. especially, I'll add an
unambigouous reference for #10.
In response to above comments, next draft will consider theses issues to be
addressed.

(3) Clarifying the comments needed: #12 and #14
Sorry, but  you lost me here. Please, give me more detail about those
questions.

(4) Further consideration needed: #4 and #10
It obviously seems that there is contradictionary statments between the
security requirement and the usage of encrypted PEPSI(#4). Also, it is
unclear how Alice can protect the data such as SII and P which passed to the
RA(#18). The solution resovled these issues will be delivered, I believe.   

Finally, three comments, #7, #13, and #20 are remained. :-)
In #7, I chose the 160-bit random number since it is easier way to get it by
using the hash algorithm. 
Next, the following text "Encrypting PEPSI with the public key of CA MUST be
derived from PEPSI along with SII ...." in Section 3.6 will be answering for
the #13.
As for the last comment, I'm sure it will be explained if the intermediate
value of PEPSI, H(H( P || R || SIItype || SII)) replaced by H( P || R ||
SIItype || SII).

Once again, thanks for your reviewing.

Best regards,
Park

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jim Schaad
Sent: Wednesday, February 25, 2004 6:51 AM
To: [e-mail]; IETF-PKIX
Subject: Comments on draft-ietf-pkix-sim-02.txt

I have the following comments in regards to this draft.

1.  Previously noted the problem with verifiers getting the value of R.

2.  Section 2.1:  Alice discloses her SII to the RA, not here PEPSI.  This
is computed by the RA.

3.  Eve is trying to determine an SII not Alice's SSN.

4.  How do you reconcile the requirement "The CA does not learn Alice's SII
or here password" with the encrypted pepsi concept presented further on in
the document.

5.  Section 2.3:  You are overloading the symbol SII.  In one case it
represents the general concept of Alice's sensitive information (section
2.1), in another ir represents SIITYPE || SII.  This is confusing.  I
suggest removing all 'Xa' items from section 2.3.

6.  Section 2.3:  What is a SIMa - this is not previously defined (is now
PEPSI)

7.  Section 3:  I worry about the length of R.  Looking at it and seeing
that it is 160-bits long, I think that somebody is going to say - oh - SHA-1
hash of SIIType || SII (maybe with the password) is a good way of getting
the random number.   On what bases is 160-bits chosen?  (Note that the
attack work load is |P| and is independent of R).

8.  Are you going to register any IANA SII Types with this document for user
convenience?  I.E.  For a USA SSN do I include the hyphens?

9.  "The SII is composed of an alphanumeric string and has a type assigned
as well." --> "The SII is composed of an alphanumeric string.  The SSItype
is an OID which defines the format and scope of the SSI value."

10.  Append to section 3.3.  Selection rule are to include requirements on
minimum lengths of the password, manditory sets of characters to be included
in the password (i.e atleast one upper case, one lower case and one numeric
charcter.)

11.  Section 3.5 - one of SHA-1 or SHA-256 needs to be a MUST (or both)

12.  Section 3.6 - If I am running a CA and I require the CA to validate the
SII, I would also require the CA to validate the PEPSI value.  Otherwise
there is no way for the CA to know that the passed along SII value and the
PEPSI value match in any way.

13.  Section 3.6 - The method of encryption needs to be specified.  Am I to
use CMS here or to actually encrypted the value with the public key of the
CA.  How do I do this if what I am using is DH?  What algorithms (bulk and
public) am I required to support to implement this feature?

14.  Section 3.7 - How do I place a PEPSI into a PKCS#10 request.  If I put
it into the attributes field as an RA, I break the signature cehck on the
certificationRequestInfo field.  This does not work.

15.  Section 3.7 - for CRMF - this item needs to be place d in the regInfo
not the controls field. (as implied by regToken being in the regCtrl arc.)

16.  Section 4.2 - Please give an exmample of where I would use the OID
id-on-sim-pepsi.  This structure is only used for hashing purposes and
therefore does not seem to need to be identified.

17.  Section 4.2 - Is this the field that I am suppose to use to pass the
data from me to the RA?  If so then authorityRandom should be optional.

18.  Section 4.2 - How to I protect the data that I am passing to the RA?

19.  Section 5.  - You have a comment about a relying parting getting an SII
from the RA -- bad news all the way around.

20.  Section 5 - text for example 3 does not may any sense to me.

21.  Section 5 - The following text "  A cryptographically secure hash
function such as SHA-1 and SHA-256 is
   recommended to use for preventing the birthday problem. " does not make
sense to me.  This does not in and of itself prevent the birthday problem  


Jim Schaad





------=_NextPart_000_00EF_01C3FBEE.5BEA8430
Content-Type: text/plain;
	name="draft-ietf-pkix-sim-02-Final.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-ietf-pkix-sim-02-Final.txt"







PKIX Working Group                                   Jongwook Park(KISA)
Internet Draft                                          Jaeho Yoon(KISA)
Document: draft-ietf-pkix-sim-02.txt                  Seungjoo Kim(KISA)
Expires : August, 2004                              Sangjoon Park(BCQRE)
Target category: Standard Track                          Jaeil Lee(KISA)
                                                       Hongsub Lee(ISTF)
                                                         Polk, Tim(NIST)
                                                          February, 2004



                Internet X.509 Public Key Infrastructure
                  Subject Identification Method (SIM)

                      <draft-ietf-pkix-sim-02.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC 2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

   This document defines Privacy-Enhanced Protected Subject Identifier
   (PEPSI) format for including a privacy sensitive identifier in the
   subjectAltName extension of a certificate.

   The PEPSI is an optional feature that may be used by a relying
   parties to determine whether the subject of a particular certificate
   is also the person corresponding to a particular sensitive



Park, et. al.             Expires - August 2004         	[Page 1]

INTERNET-DRAFT        Subject Identification Method        February 2004


   identifier.

1. Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
   as shown) are to be interpreted as described in [RFC2119].

   A Certification Authority (CA) issues X.509 public key certificates
   to bind a public key to a subject. The subject is specified through
   one or more subject names in the "subject" and/or "subjectAltName"
   fields of a certificate. The "subject" field contains a
   hierarchically structured distinguished name. The "subjectAltName
   field" may contain an electronic mail address, IP address, or other
   name forms that correspond to the subject.

   For each particular CA, a subject name corresponds to a unique
   person, device, group, or role. The CA will not knowingly issue
   certificates to multiple entities under the same name. That is, for a
   particular certificate issuer, all currently valid certificates
   asserting the same subject name(s) are bound to the same entity.

   Where the subject is a person, the name that is specified in the
   subject field of the certificate typically reflects the legal name of
   the individual and affiliated entities (e.g., their corporate
   affiliation). In reality, however, there are individuals or
   corporations that have the same or similar names. It may be difficult
   for a relying party (e.g., a person or application) to associate the
   certificate with a specific person. This ambiguity presents a problem
   for many applications.

   In some cases, applications need to ensure that the subject of
   certificates issued by different CAs are in fact the same entity.
   This requirement may be met by including a "permanent identifier" in
   all certificates issued to the same subject, which is unique across
   multiple CAs. By comparing the "permanent identifier", the relying
   party may identify certificates from different CAs that are bound to
   the same subject. This solution is defined in [PI].

   In many cases, such as a Social Security Number, a person or
   corporation's identifier is regarded as a sensitive, private or
   personal data. Such an identifier cannot simply be included as part
   of the subject field, since its disclosure lead to misuse.
   Therefore, privacy sensitive identifiers cannot be included in
   certificates as plaintext.

   On the other hand, such an identifier is not actually a secret.
   People choose to disclose these identifiers for certain classes of



Park, et. al.             Expires - August 2004         	[Page 2]

INTERNET-DRAFT        Subject Identification Method        February 2004


   transactions. For example, people may disclose their Social Security
   Number to open a bank account or obtain a loan. This is typically
   corroborated by presenting physical credentials (e.g., a driver
   license) which confirms the person's name or address.

   To support such applications in an online environment, relying
   parties need to determine whether the subject of a particular
   certificate is also the person corresponding to a particular
   sensitive identifier. Ideally, applications would leverage the
   applicants's electronic credential (e.g., the X.509 public key
   certificate) to corroborate this identifier, but the subject field of
   a certificate does not provide sufficient information.

   To fulfill these demands, this document defines the Privacy-Enhanced
   Protected Subject Identifier (PEPSI) format for including a privacy
   sensitive identifier in a certificate. When the subject of the
   certificate chooses to disclose the identifier and the relying party
   may verify the identifier.  A party that obtains the certificate
   containing a PEPSI can not determine the privacy sensitive identifier
   without performing a brute force attack, and each certificate must be
   attacked separately. Furthermore, the subject can prove to the
   relying party that they are associated with a valid identification
   without disclosing the identifier. For example, a person could prove
   they possessed a valid social security number without disclosing the
   identifier itself.

   In addition, this document defines an Encrypted PEPSI(EPEPSI) so that
   the RA and CA can exchange sensitive identifier information without
   disclosing the identifier.

   This document is organized as follows:

   - Section 2 establishes security and usability requirements;
   - Section 3 provides an overview of the mechanism;
   - Section 4 defines syntax and generation rules.

2. Requirements

2.1 Security Requirements

   Given

     - Alice, a certificate holder, with an a sensitive identifier SIIa
       (such as her Social Security Number, SSN)
     - Bob, a relying party who will rely on knowing Alice's true SII
     - Eve an attacker who has Alice's certificate
     - An RA to whom Alice must divulge her PEPSI; and
     - A CA who will issue Alice's certificate.



Park, et. al.             Expires - August 2004         	[Page 3]

INTERNET-DRAFT        Subject Identification Method        February 2004


   We wish to design a PEPSI, using a password that Alice chooses, that
   has the following properties:

     - Alice can prove her true SII, SIIa to Bob;
     - Eve has a large work factor to determine the Alice's SSN from
       her certificate, even if Alice chooses a weak password, and a
       very large work factor if  Alice chooses a good password;
     - Even if Eve can determine SIIa she has an equally hard problem
       to find any other SII from any other PEPSI; that is,there is
       nothing she can pre-compute that helps every attack against a
       PEPSI, and nothing she learns from a successful attack
       that helps in any other attack;
     - The CA does not learn Alice's SIIa or her password;
     - The CA can treat the PEPSI as an additional name form in the
       "subjectAltName" extesnion with no special processing; and
     - Alice cannot find another SII, password combination that will
       allow her to use the certificate to prove a false SII to Bob.

2.2 Usability Requirements

   In addition to the security properties stated above, we have the
   following usability requirements:

     - When the PEPSI is used, any custom processing occurs at the
       relying party. Alice can use commercial off the shelf software
       (e.g., a standard browser) without modifications.


2.3 Solution

   The solution:   Let SIM = R || PEPSI where
                   PEPSI = H(H( P || R || SIItype || SII))

   Then:

   1.      Alice picks a password, Pa, and gives Pa, SIIa to the RA.
           SIIa is composed of identifier type (SIItype) and
           identifier value SII.
   2.      The RA validates SIIa.
   3.      The RA generates a Random value R.
   4.      The RA generates the SIMa = R, PEPSI where
           PEPSIa = H(H( Pa || R || SIItype || SIIa)).
   5.      The RA passes the SIMa to the CA which generates Alice's
           certificate including the SIM as a form of otherName from
           the GeneralName structure in SubjectAltName extension.
   6.      Alice sends Bob her Cert, as well as Pa, SIIa
   7.      Bob can get R from the SIM in the cert, SIMa, then
           compute PEPSI = H(H(Pa || R || SIItype || SIIa)) and



Park, et. al.             Expires - August 2004         	[Page 4]

INTERNET-DRAFT        Subject Identification Method        February 2004


           compare it to the value in SIMa, thereby verifying SIIa.

   If Alice wishes to prove she has a valid identifier, without
   disclosing it, then steps 6 and 7 are as follows:

   6.      Alice sends intermediate value H(Pa || R || SIItype ||
           SIIa)) and her certificate to Bob.
   7.      Bob can get R form the SIM in the cert, SIMa, then
           compute H(intermediate value) and compare it to the
           value in SIMa, thereby verifying Alice's knowledge of
           Pa and SIIa.

   Eve has to exhaustively search the H(P || R || SIItype || SII) space
   to find Alice's SIIa. This is a fairly hard problem even if Alice
   uses a poor password, and a really hard problem if Alice uses a
   fairly good password.

   Even if Eve finds Alice's Pa, SIIa, pair or constructs a massive
   dictionary of P, SII pairs, it doesn't help find any other SII,
   because a new R is used for each PEPSI.

3. Procedures

3.1 Symbols

   The following cryptography symbols will be used in this document.

       H()        Cryptographically secure hash algorithm.
                  SHA-1[FIPS 180-1] or more secure hash function is
                  required.

       SII        Sensitive Identification Information.
                  (e.g, Social Security Number or Maryland Driver
                  License)

       SIItype    Object Identifier that identifies the type of SII.

       P          A user chosen password.

       R          The 160-bit random number value generated by RA.

       PEPSI      Privacy-Enhnaced Protected Subject Information.
                  Calculated from the input value P, R, SIItype, SII
                  using two iteration of H().

       E()        The public key encryption algorithm used by RA.
                  Used for encrypting the PEPSI.




Park, et. al.             Expires - August 2004         	[Page 5]

INTERNET-DRAFT        Subject Identification Method        February 2004


       EPEPSI     Encrypted PEPSI.

       D()        The public key decryption algorithm used by CA.
                  Used for decrypting the EPEPSI.

3.2 SII and SIItype

   The user presents evidence that a particular SII has been assigned to
   them. The SII is composed of an alphanumeric string and has a type
   assigned as well. For closed communities, the SII type value (e.g.,
   SSN or Social Security number) may be assigned by the CA itself.  For
   interoperability, a SII type value should be registered with IANA.

3.3 User Chosen Password

   The user selects a password as one of the input values for the SIM.
   The strength of the password is critical to protection of the user's
   SII. User should be encouraged to select passwords that will be
   difficult to guess and long enough to protect against bute force
   attacks.

   Implementations of this specification MUST permit a user to select
   passwords of up to 28 characters. RAs SHOULD implement password
   selection rules to prevent user selection of trivial passwords.

3.4 Random Number Generation

   A RA generates a 160-bit random number, "R". A new R MUST be
   generated for each SIM in a certificate.

   Whenever a certificate or key needs to be updated, a new R SHOULD be
   generated and the SIM SHOULD be recomputed. Replicating the value of
   the previous SIM from a previous certificate permits an attacker to
   identify certificates associated with the same physical person, which
   may be undesirable.

   A Random Number Generator(RNG) meets the requirements defined in
   [FIPS 140-2] is strongly recommended.

3.5 Generation of PEPSI

   The SIM in the subjectAltName extension within the certificate
   identifies an entity even it has multiple names in its certificates.
   The unique value of the SIM MUST be derived from the designated
   inputs according to the following algorithm:

      SIM = R || PEPSI
      PEPSI = H(H(P || R || SIItype || SII))



Park, et. al.             Expires - August 2004         	[Page 6]

INTERNET-DRAFT        Subject Identification Method        February 2004


   Note that the SII is known to a RA at user enrollment.  For this
   specification, H() may be SHA-1 or SHA-256.

   The syntax and associated the OID for SIM are also provided in the
   ASN.1 modules in Section 4.1.


3.6 Encryption of PEPSI

   This section will establish procedures for encrypting a SIM and SII
   along with the user chosen password for transmission across a
   network.  This may be required where the CA itself verifies SII
   before issuing the certificate.  Encrypting SIM with the public key
   of CA MUST be derived from SIM along with SII according to the
   following algorithm:

      EPEPSI = E(SII || SIM)

   The syntax and associated the OID for EPEPSI are also provided in the
   ASN.1 modules in Section 4.3.

3.7 Certification Request

   As described above, the certification request message MAY contain the
   EPEPSI. [PKCS#10] and [RFC2511] are widely used message syntaxes for
   certification requests. An EPEPSI MAY be included in optional
   attributes for conveying attributes to the CA with additional
   information.

   Basically, PKCS#10 is composed of the entity name and public key. To
   satisfy this specification, EPEPSI SHOULD be included in the
   attribute field of 'CertificateRequestInfo'.

   In case of using the RFC2511(CRMF) for certificate request message,
   an EPEPSI SHOULD enter into the 'regToken' control defined in section
   6.1 of [RFC2511].

3.8 Certification

   A CA issue certificate containing the SIM as a form of otherName from
   the GeneralName structure in "SubjectAltName" extension.

   In an environment in which a CA verifies SII before issuing the
   certificate, a CA MUST decrypt EPEPSI first with its own private key
   according to the following algorithm. It then checks the decrypted
   SII.

      SII, SIM = D(EPEPSI)



Park, et. al.             Expires - August 2004         	[Page 7]

INTERNET-DRAFT        Subject Identification Method        February 2004


4. Definition

4.1 SIM Naming Syntax

   This section specifies the syntax for SIM name form included in
   subjectAltName extension. The SIM is composed of the three fields,
   the hash algorithm identifier, the authority chosen random value, and
   the value of the PEPSI itself.

        id-on-sim OBJECT IDENTIFIER ::= {id-on ?}

        SIM ::= SEQUENCE {
            hashAlg          AlgorithmIdentifier,
            authorityRandom  BIT STRING,   -- RA chosen radom number
                                           -- used in computation of
                                           -- pEPSI
            pEPSI            OCTET STRING, -- hash of HashContent
                                           -- with algorithm hashAlg
        }

4.2 PEPSI

   This section specifies the syntax for PEPSI. The PEPSI is generated
   by performing the same hash function twice. The PEPSI is generated
   over the ASN.1 structure HashConent. HashContent has four values: the
   user selected password, the authority chosen random number, the
   identifer type, and the identifier itself.

        HashContent ::= SEQUENCE {
           userPassword     BIT STRING      -- user supplied password
           authorityRandom  BIT STRING,     -- RA chosen random number
           identifierType   OBJECT IDENTIFIER,  -- SIItype
           identifier       UTF8String,         -- SII
        }

4.3 Encrypted PEPSI

   This section describes the syntax for Encrypted PEPSI. The Encrypted
   PEPSI has two fields: identifier and PEPSI.

        EncryptedPEPSI ::= SEQUENCE {
           identifier      UTF8String,   -- SII
           sIM             OCTET STRING  -- SIM
        }







Park, et. al.             Expires - August 2004         	[Page 8]

INTERNET-DRAFT        Subject Identification Method        February 2004


5. Example Usage of SIM

   Depending on a different security environments, there are three
   possible use cases with SIM.

        1.     When a relying party doesn't have any information about
               the certificate user.
        2.     When a relying party already have the SII of certificate
               user.
        3.     When a certificate user want to disclose his SII.

   For the use case 1, SII and a user chosen password P which only a
   user know must be sent to a relying party via secure commnuication.
   Together with the password, the certificate including the SIM must be
   transmitted. Then the relying party can get R from the certificate.
   The relying party can verify that the subject of certificate issued
   by a CA is in fact the same entity who sends the password and the
   certificate.

   If comparing first two use cases, their overall procedure is almost
   same except that the SII isn't required by the relying party.
   Threfore, a certificate user transmit simply the password, P, and the
   certificate. The rest of detailed procedure is the same as that of
   the use case 1.

   For the last speical use case that a certificate user want to
   disclose his SII, the only information sent by a ceritificate user is
   the intermediate value of the PEPSI, H(R || P || SIItype || SII).
   Upon receiving of it, the relying party can verify the user by
   rehashing the value and comparing it with SIM in the certificate.

6. Security Considerations

   A cryptographically secure hash function such as SHA-1 and SHA-256 is
   recommended to use for preventing the birthday problem.  In case of
   SIM, it is impossible for an attacker to find user chosen password,
   authority random number, and sensitive identifier which generate the
   same value of SIM since SHA-1 requires 2^80 work factor where 160 is
   the bit-length of the hash value of SHA-1.

   In addition, a fairly good password is needed to protect against the
   brute force attacks on H(P || R || SIItype || SII) space.  Due to the
   short length of the SII, it is likely that an attacker can reasonably
   guess it with partial information about gender, age, and date of
   birth. Therefore it is important for users to select a fairly good
   password in order that an attacker is unable to verify whether the
   guessed SII is accurate or not unless he collects all input values
   for SIM.



Park, et. al.             Expires - August 2004         	[Page 9]

INTERNET-DRAFT        Subject Identification Method        February 2004


7. Authors' Address

   Jongwook Park
   Korea Information Security Agency
   78, Garak-Dong, Songpa-Gu, Seoul, 138-803
   REPUBLIC OF KOREA
   Phone: [phone]
   Email: [e-mail]

   Jaeho Yoon
   Korea Information Security Agency
   Phone: [phone]
   Email: [e-mail]

   Seungjoo Kim
   Korea Information Security Agency
   Phone: [phone]
   Email: [e-mail]

   Jaeil Lee
   Korea Information Security Agency
   Phone: [phone]
   Email: [e-mail]

   Sangjoon, Park
   BCQRE
   467-12, Dogok-Dong, Kangnam-Gu, Seoul, 135-270
   REPUBLIC OF KOREA
   Phone: [phone] (Ext. 200)
   EMail: [e-mail]

   Hongsub, Lee
   Internet Security Technology Forum
   78, Garak-Dong, Songpa-Gu, Seoul, 138-803
   REPUBLIC OF KOREA
   Phone: [phone]
   EMail: [e-mail]

   Tim Polk
   National Institute of Standards and Technology
   100 Bureau Drive, MS 8930
   Gaithersburg, MD 20899
   Email: [e-mail]

8. References

8.1 Normative Reference




Park, et. al.             Expires - August 2004        	[Page 10]

INTERNET-DRAFT        Subject Identification Method        February 2004


   [RFC2510]    Adams, C. and S. Farrell, "Internet X.509 Public Key
                Infrastructure, Certificate Management Protocols", RFC
                2510, March 1999.

   [RFC2511]    Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet
                X.509 Certificate Request Message Format", RFC 2511,
                March 1999.

   [RFC3280]    Housley, R., Polk, T, Ford, W. and Solo, D., "Internet
                X.509 Public Key Infrastructure Certificate and
                Certificate Revocation List (CRL) Profile", RFC 3280,
                April 2002.

   [RFC2119]    S. Bradner, "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2026]    S. Bradner, "The Internet Standards Process - Revision
                3", November 1996.


8.2 Informative Reference

   [PI]         D. Pinkas, T. Gindin, "Internet X.509 Public Key
                Infrastructure Permanent Identifier", Internet-Draft,
                January 2004.

   [X.509]      ITU-T Recommendation X.509: The Directory - Public-Key
                and Attribute Certificate Frameworks. 2000.

   [PKCS#10]    RSA Laboratories, "PKCS #10: Certification
                Request Syntax Version 1.7", November 2001.

   [FIPS 180-1] Federal Information Processing Standards Publication
                (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
                [Supersedes FIPS PUB 180 dated 11 May 1993.]

   [FIPS 140-2] Federal Information Processing Standards Publication
                (FIPS PUB) 140-2, Security Requirements for
                Cryptographic Modules, 25 May 2001.


9. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it



Park, et. al.             Expires - August 2004        	[Page 11]

INTERNET-DRAFT        Subject Identification Method        February 2004


   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

10. Acknowledgments

   Bill Burr and Morri Dworkin have contributed significantly to work on
   the PEPSI concept and identified a potential security attack.  Also
   their comments on the set of desirable properties for the PEPSI and
   enhancements to the PEPSI were most illumination.  Also, thanks for
   Russell Housely, Stephen Kent for their contribution for this
   document.

Appendix A. "Compilable" ASN.1 Module

  PKIXSIM {iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-sim(?) }

  DEFINITIONS EXPLICIT TAGS ::=

  BEGIN

  -- EXPORTS ALL

   IMPORTS

        AlgorithmIdentifier, AttributeTypeAndValue
                FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-explicit-88(1)}

   -- Arc for other name forms
   id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }

   -- Arcs for SIM, PEPSI, and EPEPSI
   id-on-sim        OBJECT IDENTIFIER ::= {id-on ?}
   id-on-sim-epepsi OBJECT IDENTIFIER ::= {id-on-sim 1}



Park, et. al.             Expires - August 2004        	[Page 12]

INTERNET-DRAFT        Subject Identification Method        February 2004


   -- SIM
   SIM ::= SEQUENCE {
      hashAlg          AlgorithmIdentifier,
      authorityRandom  BIT STRING,   -- RA chosen radom number
                                     -- used in computation of
                                     -- pEPSI
      pEPSI            OCTET STRING, -- hash of HashContent
                                     -- with algorithm hashAlg
   }

   -- PEPSI
   HashContent ::= SEQUENCE {
      userPassword     BIT STRING      -- user supplied password
      authorityRandom  BIT STRING,     -- RA chosen random number
      identifierType   OBJECT IDENTIFIER,  -- SIItype
      identifier       UTF8String,         -- SII
   }

   -- Encrypted PEPSI
   EncryptedPEPSI ::= SEQUENCE {
      identifier      UTF8String,   -- SII
      sIM             OCTET STRING  -- SIM
   }

  END

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an



Park, et. al.             Expires - August 2004        	[Page 13]

INTERNET-DRAFT        Subject Identification Method        February 2004


   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."














































Park, et. al.             Expires - August 2004        	[Page 14]

------=_NextPart_000_00EF_01C3FBEE.5BEA8430--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OLkUrU076677; Tue, 24 Feb 2004 13:46:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1OLkUUI076675; Tue, 24 Feb 2004 13:46:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OLkSBi076669 for <[e-mail]>; Tue, 24 Feb 2004 13:46:28 -0800 (PST) (envelope-from [e-mail])
Received: from romans (unknown [199.222.118.200]) by smtp1.pacifier.net (Postfix) with ESMTP id 476426F80D; Tue, 24 Feb 2004 13:46:32 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "IETF-PKIX" <[e-mail]>
Subject: Comments on draft-ietf-pkix-sim-02.txt
Date: Tue, 24 Feb 2004 13:51:05 -0800
Message-ID: <!~![e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01C3FADD.446964A0"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-MS-TNEF-Correlator: 00000000C61F957EEEE3D311963C000086335A64C4882F00
Thread-Index: AcP6X/44ZvwviwxqSgC9RQ9LVJGZ6Q==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0018_01C3FADD.446964A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I have the following comments in regards to this draft.

1.  Previously noted the problem with verifiers getting the value of R.

2.  Section 2.1:  Alice discloses her SII to the RA, not here PEPSI.  This
is computed by the RA.

3.  Eve is trying to determine an SII not Alice's SSN.

4.  How do you reconcile the requirement "The CA does not learn Alice's SII
or here password" with the encrypted pepsi concept presented further on in
the document.

5.  Section 2.3:  You are overloading the symbol SII.  In one case it
represents the general concept of Alice's sensitive information (section
2.1), in another ir represents SIITYPE || SII.  This is confusing.  I
suggest removing all 'Xa' items from section 2.3.

6.  Section 2.3:  What is a SIMa - this is not previously defined (is now
PEPSI)

7.  Section 3:  I worry about the length of R.  Looking at it and seeing
that it is 160-bits long, I think that somebody is going to say - oh - SHA-1
hash of SIIType || SII (maybe with the password) is a good way of getting
the random number.   On what bases is 160-bits chosen?  (Note that the
attack work load is |P| and is independent of R).

8.  Are you going to register any IANA SII Types with this document for user
convenience?  I.E.  For a USA SSN do I include the hyphens?

9.  "The SII is composed of an alphanumeric string and has a type assigned
as well." --> "The SII is composed of an alphanumeric string.  The SSItype
is an OID which defines the format and scope of the SSI value."

10.  Append to section 3.3.  Selection rule are to include requirements on
minimum lengths of the password, manditory sets of characters to be included
in the password (i.e atleast one upper case, one lower case and one numeric
charcter.)

11.  Section 3.5 - one of SHA-1 or SHA-256 needs to be a MUST (or both)

12.  Section 3.6 - If I am running a CA and I require the CA to validate the
SII, I would also require the CA to validate the PEPSI value.  Otherwise
there is no way for the CA to know that the passed along SII value and the
PEPSI value match in any way.

13.  Section 3.6 - The method of encryption needs to be specified.  Am I to
use CMS here or to actually encrypted the value with the public key of the
CA.  How do I do this if what I am using is DH?  What algorithms (bulk and
public) am I required to support to implement this feature?

14.  Section 3.7 - How do I place a PEPSI into a PKCS#10 request.  If I put
it into the attributes field as an RA, I break the signature cehck on the
certificationRequestInfo field.  This does not work.

15.  Section 3.7 - for CRMF - this item needs to be place d in the regInfo
not the controls field. (as implied by regToken being in the regCtrl arc.)

16.  Section 4.2 - Please give an exmample of where I would use the OID
id-on-sim-pepsi.  This structure is only used for hashing purposes and
therefore does not seem to need to be identified.

17.  Section 4.2 - Is this the field that I am suppose to use to pass the
data from me to the RA?  If so then authorityRandom should be optional.

18.  Section 4.2 - How to I protect the data that I am passing to the RA?

19.  Section 5.  - You have a comment about a relying parting getting an SII
from the RA -- bad news all the way around.

20.  Section 5 - text for example 3 does not may any sense to me.

21.  Section 5 - The following text "  A cryptographically secure hash
function such as SHA-1 and SHA-256 is
   recommended to use for preventing the birthday problem. " does not make
sense to me.  This does not in and of itself prevent the birthday problem  


Jim Schaad





------=_NextPart_000_0018_01C3FADD.446964A0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+Ig0VAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQYABwABAAAAAAAAAQOQBgAsDAAAIAAAAAsAAgABAAAAAwAmAAAA
AAACATEAAQAAABgAAAAAAAAAxh+Vfu7j0xGWPAAAhjNaZISILwAeAHAAAQAAACcAAABDb21tZW50
cyBvbiBkcmFmdC1pZXRmLXBraXgtc2ltLTAyLnR4dAAAAgFxAAEAAAAWAAAAAcP6X/44Zvwviwxq
SgC9RQ9LVJGZ6QAACwABDgAAAAACAQoOAQAAABgAAAAAAAAAxh+Vfu7j0xGWPAAAhjNaZMKAAAAD
ABQOAQAAAAIBCRABAAAACAkAAAQJAAAFEAAATFpGdboPX04DAAoAcmNwZzEyNeIyA0N0ZXgFQQED
Aff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwR
MwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFkMzYWUAumIEmCIBPgdmUgdGgdQI0CEGwXsAPwbmcgBaBe
bQeAAjAEIAuAIBggZzMLEQQgdG8dUQQAIGR0cmEBgC4KogqECoAxkC4gIFAYIHZpCGBAc2x5IG5v
DrBkjR1TcANgAmBlbSAD8L0dYCAdMAaBCJEEIGcUIDZ0HgIdYnYHQApQIG+2ZgfwIFsyITEGYGMk
UCUCICAmUDE6IUBBbOsN4B1AZAQAYxewFBAEIHMdcAXAU0kc8B+DHUBSHEEsIgIoYh1AUEVQOyiw
ITFUH8If0R5BcHVdIjJiIfApJCBbMyExReMdMR/RdHJ5JGMfkAEA+Q6wcm0LgB1AA5EosimipSdz
JwZBU04gWzQhMe5IHeAf8B+QeQhgHvEFoBxuYwMQHUQYIHF1aTMYIB5yICIqsB1AQ0H/MbEHkSmi
IvAKwAOgL8cowS8FsSnjCrAEEHcFsGQibyMkHWIJ8AUAeQUwIkFw/GVwAJAeMTJwOGAFQCKw9weQ
HoEiQWYIcB1hBcAm4Wce0R1iMcBjdR5yIFs19SZrMydBWTIBCsAlISOB7RewYSfQJHVzBsMooiEx
7kkDoAIgHUBjNpAtgQVA/xggOTUfYR1xJCAu4CAQAyB/OLYlQS/GOWEAkCRQLXJuawIQLrBhJsMo
FBAmtyn/KYAe0QBwIiAocjNQQJooscRUWSowIHx8P0UquJ9D8CHAHgE/gj7QdWckIH5zQIIEYCGQ
HhEHQAMgJ/hYYSdAYSMABCADUkMx6zynIFs2PF9XE+AFQB/R6mEooU1PAC0fpB/RKaLfOTEhlgEB
LtEiUChP4wfg9SozKSBqNyZpPSIc8DbB/y3gLwAG4CtwHVMi8B4QI1HDJUMhQExvb2tKY06x7wVA
AHAiUBQQZSRkVqQf0fIxHDAtYiNABCAXsB4QpymAKNEfwG5rV6RzA3CaZQbgZCHwH9Fnby4FbHNh
IfBPcG8jYE9wU9BIQS0xHQFzVZNHIp838B1AR6REkADAeWIdQPs3JzaGKU7EWuAEcCMgW4HfJUEk
KiAQVxBLsW47IF4wUnIhMSBPA6B3TpJin0AxKuNYZxPQKCFuPyFAfChOIiFXpB1iREABkGOfWbA2
wVmwPiIq8nxQR7D/VwIq0lcQOGAJ8AEAM6ElQvopIFs4ITEHEB1AMfJa5x8fAQQALpEvASHwSUFO
/zQwKLJdMgQgNyUf0jsFHZF/BcAhwBKBMlEdMAMAN7Fla2RxKnBFITFGBbFPAFV+U2uxMFAxshzw
C4AoAHW7AQAdU2g38B1wAIA/IGr+OSExM9MosisFKCEiUCVBvwORB0BxgABwOyEFEGM+0N8t0Epj
VxFcgU7xdF1CNpFMaWdRQnYhd2UdwC7xNwAtLT5y33PvdPsqgx94YSiwdnNO0gOgT0lE/2KRDeAj
YFEEQTREBFb0BaB/XVElQR1ie4Ek1HfAIGsw/WlycGfCWzNTdkxxJnIi8PkmtHJ1MqE9oh+BcKYz
Gf8EICbhLsEHcDsgVTWFEX7k/zaGKYADgSfQH4BUcRQRhkP/E9IA0C6RH2NeMXClZoE6lHs2hlFx
LmVyNOFJ4T/idf+BEW4RQDEpgD/iHdGMdVbzrz/idOYT0ojiLlJbMSEi+VNnLjVboi7hXNJcMwWx
+1wiDjA2IgAJ4B9UXjFPAPpNb9BURJAFsQbgHWCPjG8mWi0gkuBPcEklUBzwYfsjEIMgbgMASnI0
ElcCHPCfMxUdUzQhH4Ek4WlkREC/HUQosVkyNsCDMHcxbFog/5hfmW0qM391YlE6AgPxHUPfKgFP
42AjbaKb+GtRwmUH/zaCdyJY8iijJORXAp0th2H+dHzRRZMh8GAxIFyCRJX6/zPiB4AdYGABJUE3
tSbSkwruczhQMoAjwWRpciMQKNN/beESIAXhKeOf8h+QiNF130qhIfA3uCSoXmh1AmB1MfxrZWBT
m/QxWBzwMcFPlJ8lUGKjluNI8yryREhkcT9OgwdAWuAFEB1gS2EoYv+DMFmwVwKudF9wlwGYR4FU
f4xBF8GDoytQIvEzkh+zZm808KwwGCBx2zExQpCoN/9PYa/nC1EnoU8AnWQLgKvi4SFQS0NTI4Cw
MwNJ0f8/gpbCK2FX87tiZVUFELOwfw6wS3EIkJryfBMpYhzwYn0YIGFZsj7BdvG3kx4wZf5oZdEm
4R1iJ6AAICOxQCD9JsJSvFQ/sAIQvtQqhjRXH2YCIFw8SrmEbaJDUk3+Rk9nS0GS+7p0ihcfAcNT
vymiwdMCIQNgmzDDlih2Ie+2gqoBK7IfAVRWQAnwiWH7sePJ50Mt0AMgjxGPfU1q9zFAFEBPcFCL
okFxQ6IDkf8OwADAtpIlMmKgKfKapqriVx1ifGKZsC0CIC0AkG3+LThTKoZ1YRrQwPMf0QIgfyHh
beE5sTYCXJEeAitgcv95InwSIlMYIEQBOtI0dVdB/yMQH4GTAok2Z/Kp5CBrUyr90PRJQTItoh1y
vvNXs5bj/7XTnrKqxB+BNoI6pERATwD/S5MHgCjobuIlUJtBHWFFoecrcGQgszF5UmF0XKCa0/9e
MX6QJsIHQCBcaWLQfDGC/x+BulEDYA6wJrDhON84NoL/LgXihSBrcqImljxCT3A9Yv8dE08AHkVU
lU8AGCAh4NgD/wrAJFMkJi8VS5MpJHfhYuH7IlAu4HdO4UqxHWJgMgrA/whgVxAljIDC7FdPYg7C
baL7DsDSdDM0SF4BazNDQoOT/weAJYyQapFCM+IdqA6zNwDXEMAeMDfibwnAYXGAwnH/rGJEscEC
XIM50DJwJsNJkP980XYhXCRXApKGBAAgxGJB/zIyHmKJ8qq1x0JQUtuSJHX/WKA58ZnAIfAitSEw
NwD2if+u4PeLxA5Fk3ljWLF3kCVQvwHVAn8i4wrjIKYgxEq2gF8mgBPRPkAJnwnrfQ1AAgEUOgEA
AAAQAAAAppH8WmdMb0OmlIc9nH5IZgMA3j+fTgAAAwAJWQEAAAADAACACCAGAAAAAADAAAAAAAAA
RgAAAAAQhQAAAAAAAAsABYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwAGgAggBgAAAAAA
wAAAAAAAAEYAAAAAAYUAAAAAAAALAAeACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsACIAI
IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAA
AAALABaACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsAHw4BAAAAAgH4DwEAAAAQAAAAxh+V
fu7j0xGWPAAAhjNaZAIB+g8BAAAAEAAAAMYflX7u49MRljwAAIYzWmQDAP4PBQAAAAMADTT9PwMA
AwAPNP0/AwACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDBD
NjFGOTU3RUVFRTNEMzExOTYzQzAwMDA4NjMzNUE2NEM0ODgyRjAwAAAAAAMABhCcW7LLAwAHEL0K
AAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAASUhBVkVUSEVGT0xMT1dJTkdDT01NRU5UU0lO
UkVHQVJEU1RPVEhJU0RSQUZUMVBSRVZJT1VTTFlOT1RFRFRIRVBST0JMRU1XSVRIVkVSSUZJRVJT
R0VUVElOR1RIRVZBTFVFTwAAAADE3Q==

------=_NextPart_000_0018_01C3FADD.446964A0--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1O5u3Mo050274; Mon, 23 Feb 2004 21:56:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1O5trTf050269; Mon, 23 Feb 2004 21:55:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1O5tWLo050248 for <[e-mail]>; Mon, 23 Feb 2004 21:55:48 -0800 (PST) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.197.53]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id i1O5qRkn006093 for <[e-mail]>; Tue, 24 Feb 2004 10:52:34 +0500 (PKT)
Message-ID: <001d01c3fa9c$14beb2f0$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: <[e-mail]>
Subject: Relationship between SAN and IAN?
Date: Tue, 24 Feb 2004 11:04:24 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C3FAC5.F6539540"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

H=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=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_001A_01C3FAC5.F6539540
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<=00/=00H=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>=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/=00L=00I=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_001A_01C3FAC5.F6539540--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NKQais016686; Mon, 23 Feb 2004 12:26:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1NKQaLE016685; Mon, 23 Feb 2004 12:26:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NKQYHk016679 for <[e-mail]>; Mon, 23 Feb 2004 12:26:34 -0800 (PST) (envelope-from [e-mail])
Received: from Russ-Laptop.verizon.net ([141.156.171.148]) by out002.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <[e-mail]>; Mon, 23 Feb 2004 14:26:38 -0600
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 23 Feb 2004 15:26:32 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-sonof3039 is Approved 
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [141.156.171.148] at Mon, 23 Feb 2004 14:26:37 -0600
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

Steve Bellovin reminded me that RFC 2418 provides guidance in this 
area.  It says:

    3.3. Session management

    Working groups make decisions through a "rough consensus" process.
    IETF consensus does not require that all participants agree although
    this is, of course, preferred.  In general, the dominant view of the
    working group shall prevail.  (However, it must be noted that
    "dominance" is not to be determined on the basis of volume or
    persistence, but rather a more general sense of agreement.) Consensus
    can be determined by a show of hands, humming, or any other means on
    which the WG agrees (by rough consensus, of course).  Note that 51%
    of the working group does not qualify as "rough consensus" and 99% is
    better than rough.  It is up to the Chair to determine if rough
    consensus has been reached.

Unanimity is not required for rough consensus.  Steve Kent pointed out in 
his message that all of your comments were considered, even thought they 
were not all accepted.

I think it is time to move along.  I think we are done with Son Of  RFC 
3039, and nothing in this thread has convinced me otherwise.  Of course, 
you are free to submit an appeal if he feels strongly to the contrary.

Russ






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NK1sKI015323; Mon, 23 Feb 2004 12:01:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1NK1sxN015322; Mon, 23 Feb 2004 12:01:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NK1phT015313 for <[e-mail]>; Mon, 23 Feb 2004 12:01:52 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Feb 2004 20:01:50 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Feb 2004 20:01:50 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Feb 2004 20:01:50 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-sonof3039 is Approved
Date: Mon, 23 Feb 2004 20:01:45 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-sonof3039 is Approved
Thread-Index: AcP6Q5nAhbYwzXd3T0alZVpCX5Rw7wAAWJEw
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Feb 2004 20:01:50.0131 (UTC) FILETIME=[DFD38830:01C3FA47]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i1NK1qhT015316
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Some corrections below;

/Stefan

Stefan Santesson
Program Manager, Windows Security
Principal Consultant, Microsoft Denmark

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 23 februari 2004 17:59
> To: Russ Housley
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: draft-ietf-pkix-sonof3039 is Approved
> 
> 
> Russ,
> 
> > Denis:
> 
> > After WG Last Call was closed, you submitted 38 comments.  These
> > comments were not ignored, they were considered during IETF Last
Call.
> > Stefan Santesson posted a detailed response of each of your comments
on
> > January 30th.  This message was sent to PKIX mail list.
> 
> > Stefan met with you in Barcelona during the ETSI meeting and
explained
> > the changes that were made.  Stefan reported that you seemed happy,
> 
> Stefan made a wrong report.

No I didn't I expressed my impression. My impression was that we left
each other in Barcelona in some good space with a feeling of having
agreed on all important issues.

Yes I knew that you still might have some issues but you were supposed
to e-mail them to me. I have seen nothing from you.

> 
> The best way to ask if someone is pleased or not is to ask him, and
wait
> for
> the reply (or else use an acknowledge of receipt and wait). At the
> Barcelona
> meeting, Stefan DID know that I was not pleased with the resolution he
> proposed to many of my comments.
> 
> I offered him to discuss the comments during the evenings, but Stefan
> prefred to go hiking in the evening on the Barcelona hills.
> 

And I offered you to work between 8 - 9 a.m. before the ETSI meeting but
you choose to sleep, as you apparently have chosen during the majority
of the development of this draft.

> Fine it is his choice. I also proposed Thursday, but Stefan prefered
to
> take
> a flight on the Wednesday evening. It was HIS choice, not mine.
> 
> In th eonly "evening" (he left at 5:20 p.m.) he ahd available Stefan
> wanted
> to give priority to discuss the ISO DTC 6 about X.509 with Jane Hill,
so
> we
> spent the time he had available only on that topic. 

It was my choice to start with this discussion because agreement on this
issue had high impact on our discussion of RFC 3039bis. It was YOUR
decision to continue to work on that issue after reaching concensus,
despite knowing my time constraints.

> We did not discussed my
> comments on sonof3039.
> 

That is a pure lie (or just bad memory). We actually went quite a bit
through the list of comments and their resolution in draft 05. We ended
somewhere in the discussion of the qc-compliance declarations but jumped
to the overall picture and the key-usage issues where you wanted to have
rewording of the security considerations section.

> > except you expressed a wish to add something to the security
> > considerations section.  Stefan asked for you to contribute text,
but it
> > never came, well at least not before today.
> 
> I do not have such a request from Stefan.

Again, a lie or just bad memory. I asked you, and you responded
confirmatively, that you would provide me with a new proposed text for
the security considerations section. I stand by that I will try to help
to any reasonable extent to get such text in the final RFC, if accepted
by the IESG.

> 
> > Steve Kent sent the attached note confirming that the PKIX WG had
> > reached consensus.  Steve confirms that all of you comments were
> > considered, although not all of them were accepted.
> 
> I have not seen nor received the note from Steve since it was not
posted
> to
> the PKIX Mailing list !
> 
> > The revised document was posted as draft-ietf-pkix-sonof3039-05, and
> > that document was reviewed by the IESG for the telechat last
Thursday.
> 
> I have not been informed.
> 
> > The IESG approved the document, with one point needing to be cleared
> > up.  That point was cleared up last Saturday.
> >
> > The secretariat should be sending an approval announcement today.
> 
> > If you were not happy with the way that your comments were handled,
you
> > should have spoken up long before today.
> 
> I do not think that Stefan made a fair report of what happened in
> Barcelona.
> So what follows is not a fair process.

I have not made any such report. I have just given you a fair chance to
state your issues and promptly responded to any issues you have made
public or made known to me.

I'm still not aware of what your problems are - after the response to
you - other than those I have mentioned.

> 
> The usual procedure is to try to solve all comments, and this process
> takes
> some time.
> 
> So why is this draft going so fast while others are waiting months or
even
> years for approval ? Is it because ... ?
> 
> I also notice that the mail from Steve is on February 2, so well
BEFORE
> the
> Barcelona meeting which finished on February 12 th.
> 
> Coming back on the mailing list 11 days after the end of that meeting
> seems
> perfectly reasonable to me.
> 
> I would like you to report these facts at the IESG level and that the
> IESG,
> taking notice of these *facts*, reconsiders his position.
> 
> Denis
> 
> 
> 
> > Russ
> >
> >
> >> Date: Mon, 2 Feb 2004 17:46:43 -0500
> >> To: Russ Housley <[e-mail]>
> >> From: Stephen Kent <[e-mail]>
> >> Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
> >> Cc: "Stefan Santesson" <[e-mail]>, "Tim Polk"
> >> <[e-mail]>,
> >>    "Magnus Nystrom" <[e-mail]>, Stephen  Kent
> >> <[e-mail]>
> >>
> >> Russ,
> >>
> >>>
> >>>> Would this be OK or do I need to get consensus with Denis an all
38
> >>>> items on the list :-)
> >>>
> >>>
> >>> We need Tim and Steve to be involved in this process.  They are
the
> >>> ones that need to determine 'rough consensus' for this document.
I
> >>> need to be satisfied that Last Call comments have been considered
and
> >>> resolved without breaking the rough consensus.  To this end, I
want
> >>> to see a response to each comment posted to the PKIX list. This
will
> >>> allow others to object if the change breaks the consensus.
> >>
> >>
> >> I am satisfied that the WG, based on the mail on the list, is
> >> satisfied with the version of 3039bis that we now have.  Denis's
> >> issues have been dealt with, or at least considered, and we can
> proceed.
> >>
> >> Steve
> >>
> >
> >
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NICvBV007657; Mon, 23 Feb 2004 10:12:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1NICvn5007656; Mon, 23 Feb 2004 10:12:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NICtYA007648 for <[e-mail]>; Mon, 23 Feb 2004 10:12:56 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1NICHMB011018; Mon, 23 Feb 2004 13:12:18 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020418bc5fe97f98d0@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Mon, 23 Feb 2004 12:38:52 -0500
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft-ietf-pkix-sonof3039 is Approved
Cc: Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

In the case of this document you have made a number of comments in 
the past (going back to at least March or 2003) and Stefan has 
responded to them, many more than once.  We are aware that not all of 
his responses have been to your satisfaction. In fact, your have even 
questioned the need to revise the extant RFC. However, the WG chairs 
have not seen any substantive comments re these residual issues from 
any other WG members. We thus determined that there was WG consensus, 
and notified the ADs accordingly.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NHaX4B005085; Mon, 23 Feb 2004 09:36:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1NHaWsH005084; Mon, 23 Feb 2004 09:36:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1NHaT7S005070 for <[e-mail]>; Mon, 23 Feb 2004 09:36:31 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 17822 invoked by uid 0); 23 Feb 2004 17:34:40 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.173.217) by woodstock.binhost.com with SMTP; 23 Feb 2004 17:34:40 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 23 Feb 2004 12:36:26 -0500
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-sonof3039 is Approved
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

I am simply reporting the events as I understand them.

I know that Steve Kent's message to me came prior to the meeting in 
Barcelona.  My understanding of the face-to-face meeting between you and 
Stefan was simply a matter of lucky scheduling.  The two of you happened to 
be at the same place at the same time at a non-IETF related event.  This 
situation allowed Stefan to review how each of the comments was handled -- 
accepted or rejected.  The point was to make sure you were aware of the 
ones that were rejected, and that you were happy with the wording of the 
ones that were accepted.

Prior to meeting with you, Stefan sent me a note indicating that he would 
do so:

 > Denis is here at ETSI and he approached me indicating that he want to 
discuss
 > these issues but I fear that we won't be able to come to a mutual 
agreement here
 > and now on every single bit. I will listen to him and see if there is 
anything he can
 > add to this that makes sense. <snip>
 > I will let you know about any change proposals as a result of my 
discussion with
 > Denis so that you can approve or reject them before publication of draft 05.

This seems like a very reasonable approach, especially since IETF Last Call 
had already closed without any response to the comment resolution 
message.  As I have already stated, the message about your comments was 
sent to the PKIX mail list on January 30th.

I placed this document on the IESG telechat agenda on February 12th.  At no 
time between January 30th and today did you send a message to the PKIX mail 
list, the PKIX WG chair, or me indicating that you were unhappy with the 
way your comments were handled.

The timing of the Barcelona meeting is irrelevant to these key dates.

Steve Kent's message was a response to a query from Stefan to me.  I was 
clear that it is up to the WG Chair to determine consensus.  Steve did so, 
after IETF Last Call ended.  And from Steve's message, it is clear that he 
understood that some of your comments were being rejected.

Russ

At 05:58 PM 2/23/2004 +0100, Denis Pinkas wrote:
>Russ,
>
>>Denis:
>
>>After WG Last Call was closed, you submitted 38 comments.  These comments 
>>were not ignored, they were considered during IETF Last Call.
>>Stefan Santesson posted a detailed response of each of your comments on 
>>January 30th.  This message was sent to PKIX mail list.
>
>>Stefan met with you in Barcelona during the ETSI meeting and explained 
>>the changes that were made.  Stefan reported that you seemed happy,
>
>Stefan made a wrong report.
>
>The best way to ask if someone is pleased or not is to ask him, and wait 
>for the reply (or else use an acknowledge of receipt and wait). At the 
>Barcelona meeting, Stefan DID know that I was not pleased with the 
>resolution he proposed to many of my comments.
>
>I offered him to discuss the comments during the evenings, but Stefan 
>prefred to go hiking in the evening on the Barcelona hills.
>
>Fine it is his choice. I also proposed Thursday, but Stefan prefered to 
>take a flight on the Wednesday evening. It was HIS choice, not mine.
>
>In th eonly "evening" (he left at 5:20 p.m.) he ahd available Stefan 
>wanted to give priority to discuss the ISO DTC 6 about X.509 with Jane 
>Hill, so we spent the time he had available only on that topic. We did not 
>discussed my comments on sonof3039.
>
>>except you expressed a wish to add something to the security 
>>considerations section.  Stefan asked for you to contribute text, but it 
>>never came, well at least not before today.
>
>I do not have such a request from Stefan.
>
>>Steve Kent sent the attached note confirming that the PKIX WG had reached 
>>consensus.  Steve confirms that all of you comments were considered, 
>>although not all of them were accepted.
>
>I have not seen nor received the note from Steve since it was not posted 
>to the PKIX Mailing list !
>
>>The revised document was posted as draft-ietf-pkix-sonof3039-05, and that 
>>document was reviewed by the IESG for the telechat last Thursday.
>
>I have not been informed.
>
>>The IESG approved the document, with one point needing to be cleared 
>>up.  That point was cleared up last Saturday.
>>The secretariat should be sending an approval announcement today.
>
>>If you were not happy with the way that your comments were handled, you 
>>should have spoken up long before today.
>
>I do not think that Stefan made a fair report of what happened in Barcelona.
>So what follows is not a fair process.
>
>The usual procedure is to try to solve all comments, and this process 
>takes some time.
>
>So why is this draft going so fast while others are waiting months or even 
>years for approval ? Is it because ... ?
>
>I also notice that the mail from Steve is on February 2, so well BEFORE 
>the Barcelona meeting which finished on February 12 th.
>
>Coming back on the mailing list 11 days after the end of that meeting 
>seems perfectly reasonable to me.
>
>I would like you to report these facts at the IESG level and that the 
>IESG, taking notice of these *facts*, reconsiders his position.
>
>Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NHaXHd005086; Mon, 23 Feb 2004 09:36:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1NHaWUu005083; Mon, 23 Feb 2004 09:36:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1NHaTDV005071 for <[e-mail]>; Mon, 23 Feb 2004 09:36:31 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 17828 invoked by uid 0); 23 Feb 2004 17:34:41 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.173.217) by woodstock.binhost.com with SMTP; 23 Feb 2004 17:34:41 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 23 Feb 2004 12:35:30 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-pkix-sonof3039 is Approved
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

After WG Last Call was closed, you submitted 38 comments.  These comments 
were not ignored, they were considered during IETF Last Call.  Stefan 
Santesson posted a detailed response of each of your comments on January 
30th.  This message was sent to PKIX mail list.

Stefan met with you in Barcelona during the ETSI meeting and explained the 
changes that were made.  Stefan reported that you seemed happy, except you 
expressed a wish to add something to the security considerations 
section.  Stefan asked for you to contribute text, but it never came, well 
at least not before today.

Steve Kent sent the attached note confirming that the PKIX WG had reached 
consensus.  Steve confirms that all of you comments were considered, 
although not all of them were accepted.

The revised document was posted as draft-ietf-pkix-sonof3039-05, and that 
document was reviewed by the IESG for the telechat last Thursday.  The IESG 
approved the document, with one point needing to be cleared up.  That point 
was cleared up last Saturday.

The secretariat should be sending an approval announcement today.

If you were not happy with the way that your comments were handled, you 
should have spoken up long before today.

Russ


>Date: Mon, 2 Feb 2004 17:46:43 -0500
>To: Russ Housley <[e-mail]>
>From: Stephen Kent <[e-mail]>
>Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
>Cc: "Stefan Santesson" <[e-mail]>, "Tim Polk" <[e-mail]>,
>    "Magnus Nystrom" <[e-mail]>, Stephen  Kent <[e-mail]>
>
>Russ,
>
>>
>>>Would this be OK or do I need to get consensus with Denis an all 38
>>>items on the list :-)
>>
>>We need Tim and Steve to be involved in this process.  They are the ones 
>>that need to determine 'rough consensus' for this document.  I need to be 
>>satisfied that Last Call comments have been considered and resolved 
>>without breaking the rough consensus.  To this end, I want to see a 
>>response to each comment posted to the PKIX list. This will allow others 
>>to object if the change breaks the consensus.
>
>I am satisfied that the WG, based on the mail on the list, is satisfied 
>with the version of 3039bis that we now have.  Denis's issues have been 
>dealt with, or at least considered, and we can proceed.
>
>Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NGx3DC003221; Mon, 23 Feb 2004 08:59:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1NGx3G0003220; Mon, 23 Feb 2004 08:59:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NGx0DD003212 for <[e-mail]>; Mon, 23 Feb 2004 08:59:01 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA30826; Mon, 23 Feb 2004 18:07:06 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id SAA27837; Mon, 23 Feb 2004 18:54:42 +0100
Message-ID: <[e-mail]>
Date: Mon, 23 Feb 2004 17:58:59 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-sonof3039 is Approved
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> Denis:

> After WG Last Call was closed, you submitted 38 comments.  These 
> comments were not ignored, they were considered during IETF Last Call.  
> Stefan Santesson posted a detailed response of each of your comments on 
> January 30th.  This message was sent to PKIX mail list.

> Stefan met with you in Barcelona during the ETSI meeting and explained 
> the changes that were made.  Stefan reported that you seemed happy,

Stefan made a wrong report.

The best way to ask if someone is pleased or not is to ask him, and wait for 
the reply (or else use an acknowledge of receipt and wait). At the Barcelona 
meeting, Stefan DID know that I was not pleased with the resolution he 
proposed to many of my comments.

I offered him to discuss the comments during the evenings, but Stefan 
prefred to go hiking in the evening on the Barcelona hills.

Fine it is his choice. I also proposed Thursday, but Stefan prefered to take 
a flight on the Wednesday evening. It was HIS choice, not mine.

In th eonly "evening" (he left at 5:20 p.m.) he ahd available Stefan wanted 
to give priority to discuss the ISO DTC 6 about X.509 with Jane Hill, so we 
spent the time he had available only on that topic. We did not discussed my 
comments on sonof3039.

> except you expressed a wish to add something to the security 
> considerations section.  Stefan asked for you to contribute text, but it 
> never came, well at least not before today.

I do not have such a request from Stefan.

> Steve Kent sent the attached note confirming that the PKIX WG had 
> reached consensus.  Steve confirms that all of you comments were 
> considered, although not all of them were accepted.

I have not seen nor received the note from Steve since it was not posted to 
the PKIX Mailing list !

> The revised document was posted as draft-ietf-pkix-sonof3039-05, and 
> that document was reviewed by the IESG for the telechat last Thursday.  

I have not been informed.

> The IESG approved the document, with one point needing to be cleared 
> up.  That point was cleared up last Saturday.
> 
> The secretariat should be sending an approval announcement today.

> If you were not happy with the way that your comments were handled, you 
> should have spoken up long before today.

I do not think that Stefan made a fair report of what happened in Barcelona.
So what follows is not a fair process.

The usual procedure is to try to solve all comments, and this process takes 
some time.

So why is this draft going so fast while others are waiting months or even 
years for approval ? Is it because ... ?

I also notice that the mail from Steve is on February 2, so well BEFORE the 
Barcelona meeting which finished on February 12 th.

Coming back on the mailing list 11 days after the end of that meeting seems 
perfectly reasonable to me.

I would like you to report these facts at the IESG level and that the IESG, 
taking notice of these *facts*, reconsiders his position.

Denis



> Russ
> 
> 
>> Date: Mon, 2 Feb 2004 17:46:43 -0500
>> To: Russ Housley <[e-mail]>
>> From: Stephen Kent <[e-mail]>
>> Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
>> Cc: "Stefan Santesson" <[e-mail]>, "Tim Polk" 
>> <[e-mail]>,
>>    "Magnus Nystrom" <[e-mail]>, Stephen  Kent 
>> <[e-mail]>
>>
>> Russ,
>>
>>>
>>>> Would this be OK or do I need to get consensus with Denis an all 38
>>>> items on the list :-)
>>>
>>>
>>> We need Tim and Steve to be involved in this process.  They are the 
>>> ones that need to determine 'rough consensus' for this document.  I 
>>> need to be satisfied that Last Call comments have been considered and 
>>> resolved without breaking the rough consensus.  To this end, I want 
>>> to see a response to each comment posted to the PKIX list. This will 
>>> allow others to object if the change breaks the consensus.
>>
>>
>> I am satisfied that the WG, based on the mail on the list, is 
>> satisfied with the version of 3039bis that we now have.  Denis's 
>> issues have been dealt with, or at least considered, and we can proceed.
>>
>> Steve
>>
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NDk4ZN089878; Mon, 23 Feb 2004 05:46:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1NDk3qZ089876; Mon, 23 Feb 2004 05:46:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NDjtJi089861 for <[e-mail]>; Mon, 23 Feb 2004 05:45:57 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA18106; Mon, 23 Feb 2004 14:53:21 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA26346; Mon, 23 Feb 2004 15:40:53 +0100
Message-ID: <[e-mail]>
Date: Mon, 23 Feb 2004 14:45:09 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail], Magnus Nystrom <[e-mail]>, Tim Polk <[e-mail]>, Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Let us go for the good news first. Out of the 38 initial comments,
14 are solved, accepted or agreed. They have the following numbers:
3, 8, 11, 12, 14, 17, 18, 19, 20, 21, 23, 29, 31, 38.

The bad news is that 24 are not yet solved.

I will prepare responses to these 23 comments.

Denis

> Denis,
> 
>  
> 
> Excuse me for taking a while to respond but you gave me quite a piece to 
> work on :-).
> 
>  
> 
> So, here is the response and suggested resolutions (in-line below).
> 
> Quite a few of your comments have resulted in change proposals, while 
> others haven?t (as it usually is).
> 
>  
> 
> But I hope you will find the response below reasonable.
> 
>  
> 
> Thanks for your extensive efforts in challenging the document.
> 
>  
> 
> /Stefan
> 
>  
> 
>  
> 
> -----Original Message-----
> 
> From: Denis Pinkas [mailto:[e-mail]]
> 
> Sent: den 26 januari 2004 10:05
> 
> To: Stefan Santesson; Tim Polk; Magnus Nystrom
> 
> Cc: [e-mail]
> 
> Subject: Re: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
> 
>  
> 
> Stefan, Magnus and Tim,
> 
>  
> 
> Please find 38 comments on <draft-ietf-pkix-sonof3039-03.txt>
> 
>  
> 
> 1. The text states:
> 
>  
> 
>     "The profile defines specific conventions for certificates that are
> 
>     qualified within a defined legal framework, named Qualified
> 
>     Certificates."
> 
>  
> 
> It is unclear what the topic of this document is about. This sentence 
> does not explain. To illustrate the concern if we had the following 
> sentence, it would be the same problem :
> 
>  
> 
>    "The profile defines specific conventions for certificates that are
> 
>     certified within a defined legal framework, named Certified
> 
>     Certificates."
> 
>  
> 
> What means qualified ? What would mean certified ?
> 
>  
> 
> Since the definition of a legal framework is outside the scope, it could 
> be any kind of certificate as long as it is issued for a natural person, 
> which is the only restriction advertised. Then why is it under a "legal 
> framework"
> 
> ? It would be appropriate under any kind of certificate policy. The text 
> should not place any emphasis on a "legal framework".
> 
>  
> 
> This document simply defines a profile of a certificate for natural persons.
> 
>  
> 
> The technical content of this document should be clearly advertised.
> 
> Hereafter is a proposal, intended to be a full replacement of the second 
> paragraph :
> 
>  
> 
>     ?This document provides a profile for two fields: issuer and
> 
>     subject and for three certificate extensions: subject alternate
> 
>     name, subject directory attributes, and key usage. It also defines
> 
>     two extensions: biometric information and qualified certificate
> 
>     statements?.
> 
>  
> 
>  
> 
> Reply
> 
> This has been debated before and the conclusion for this standard is 
> that this standard should remain its name and connection to the 
> Qualified Certificate concept. This is a technical standard and not a 
> legal standard. The term Qualified Certificates and the way it is used 
> in this standard gives a reasonable background and justification for the 
> provided technical specifications in section 3.
> 
>  
> 
> This standard does not make legal definitions and does not reference any 
> specific legal framework as source of requirements but it is the 
> editors? conclusion that it is appropriate to informatively talk about 
> legal frameworks as a general source or requirements that effects 
> practical implementations. This was also done in RFC 3039 with your consent.
> 
>  
> 
> The text you provide is handled in Comment 24.
> 
>  
> 
> Proposed resolution:
> 
> No action in the abstract. Proposed text is handled under comment 24
> 
>  
> 
>  
> 
> 2. The use of the wording "Qualified Certificate" is unfortunate since 
> it creates a confusion with the same wording used in the European 
> Directive on Electronic Signatures.
> 
>  
> 
> If the wording "qualified certificate" needs to be kept, a warning 
> should be given in the abstract. In order to avoid readers to 
> misunderstand what is a qualified certificate in the context of this 
> document, the following sentence should be added:
> 
>  
> 
> "It should be noticed that the meaning of "Qualified Certificate" as 
> used in this document is different from the same wording used in the 
> European Directive on Electronic Signatures."
> 
>  
> 
> The European Directive on Electronic Signatures should be referenced in 
> the informative reference section.
> 
>  
> 
> Reply
> 
> The WG has discussed and decided to keep the term ?Qualified Certificate?.
> 
> I agree with the inclusion of the reference; however, the rest would 
> seem to mislead the reader.  The Directive is used as an example of 
> local legal documentation
> 
>  
> 
> Proposed resolution:
> 
> Include Reference to Directive in the reference section
> 
>  
> 
>  
> 
> 3. In section 1, 6 th paragraph, the text states:
> 
>  
> 
>     "It should be noted that this specification does not define the
> 
>     specific semantics of Qualified Certificates, and does not define the
> 
>     policies that should be used with them.  That is, this document
> 
>     defines what information should go into Qualified Certificates, but
> 
>     not what that information means.  A system that uses Qualified
> 
>     Certificates must define its own semantics for the information in
> 
>     Qualified Certificates.  It is expected that laws and corporate
> 
>     policies will make these definitions."
> 
>  
> 
> This is not true. The only semantics which is undefined is the semantics of
> 
> specific Qualified Certificate Statements. Please delete.
> 
>  
> 
> Reply
> 
> This is an old text from RFC 3039 that I don?t mind deleting. It was 
> formulated by Paul Hoffman who strongly believed that this clarification 
> was needed. This was done in an early state of the RFC 3039 process and 
> I don?t think it is relevant anymore given its current form. Unless Paul 
> comes forth and objects strenuously, I agree to delete.
> 
>  
> 
> Proposed resolution:
> 
> Delete sentence
> 
>  
> 
>  
> 
> 4. The text states:
> 
>  
> 
> "This specification differs from RFC 3039 in the following basic areas:
> 
>  
> 
>        * Some editorial clarifications has been made to introductory
> 
>        sections to clarify that this profile is generally applicable to a
> 
>        broad type of certificates even if its prime purpose is to
> 
>        facilitate issuance of Qualified Certificates."
> 
>  
> 
> The abstract states :
> 
>  
> 
> " The profile is however not limited to Qualified Certificates and
> 
>    further profiling may facilitate specific local needs."
> 
>  
> 
> Since a Qualified Certificate is a profile limited to natural person, it is
> 
> unclear to understand what this sentence means. Please delete.
> 
>  
> 
> Reply
> 
> This is just informative text and not part of any normative definitions. 
> As such it is a relevant description of changes made to the document.
> 
>  
> 
> Proposed resolution:
> 
> No action
> 
>  
> 
>  
> 
> 5. The text states:
> 
>  
> 
>        * To better facilitate broad applicability of this profile some
> 
>        constraints on key usage settings in the key usage extension has
> 
>        been removed.
> 
>  
> 
> This "constraints" were a recommendation that is still true and is 
> currently
> 
> proposed to be included to answer to a "defect report" raised on key usage
> 
> on X.509 / IS0 9594-8. It is likely that this constraint will be accepted.
> 
> This explanation should be removed and the recommendation that is 
> present in
> 
> RFC 3039 should remain.
> 
>  
> 
> Reply
> 
> This particular issue has been discussed and concluded in the WG. The 
> statement made in RFC 3039 is good practice in many situations but it 
> isn?t a general truth. There is no context in RFC 3039 to make such 
> statement and therefore it has been moved to ETSI TS 102 280 where there 
> is an applicable context for this recommendation. AFAIK you have never 
> argued against this, just maintained your position out of principles.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 6. The text states:
> 
>  
> 
>        * A new qc-Statement reflecting this second version of the profile
> 
>        has been defined in Section 3.2.5.1
> 
>  
> 
> What about backwards compatibility ?
> 
> Has anybody used the predefined qcStatement-1 ? Until we got a confirmed no
> 
> response, it is not possible to suppress the document (i.e. RFC 3039) which
> 
> tells what it means. Otherwise, implementations based on RFC3039 will
> 
> suddenly become invalid. If nobody has ever implemented the predefined
> 
> qcStatement-1, then there would be no reason to support it in 3039bis.
> 
>  
> 
> Reply
> 
> This has been fixed in draft 04 where it is clearly defined that 
> reference to RFC 3039 is deprecated for new certificates.
> 
>  
> 
> Proposed resolution:
> 
> No change (fixed in draft 04)
> 
>  
> 
>  
> 
> 7. The text states in section 2 , Requirements and Assumptions.
> 
>  
> 
>     "The term "Qualified Certificate" has been used by the European
> 
>     Commission to describe a certain type of certificates with specific
> 
>     relevance for European legislation.  This specification is intended
> 
>     to support this class of certificates, but its scope is not limited
> 
>     to this application.
> 
>  
> 
>     Within this standard the term "Qualified Certificate" is used
> 
>     generally, describing a certificate whose primary purpose is to
> 
>     identify a person with high level of assurance, where the certificate
> 
>     meet some qualification requirements defined by an applicable legal
> 
>     framework. The actual mechanisms that decide whether a certificate
> 
>     should or should not be considered to be a "Qualified Certificate" in
> 
>     regard to any legislation are outside the scope of this standard."
> 
>  
> 
> Full text proposal replacement:
> 
>  
> 
>     "The term "Qualified Certificate" is used by the European Directive
> 
>     on Electronic Signature to refer to specific type of certificate.
> 
>     The same term is used in this document with a different meaning,
> 
>     i.e. to define a profile of a certificate issued to natural persons,
> 
>     and which imposes constraints on the structure of the name of the
> 
>     subject and of the issuer."
> 
>  
> 
> Reply
> 
> The first part of your replacement text is good, the rest is misleading. 
> The use of Qualified Certificate is used to describe the same thing in 
> both documents, just in different contexts, not with different meaning.
> 
>  
> 
> Proposed resolution:
> 
> Change first section to:
> 
> "The term "Qualified Certificate" is used by the European Directive
> 
>  on Electronic Signature [EU-SIGDIR] to refer to a specific type of
> 
>  certificates, with appliance in European electronic signature
> 
>  legislation. This specification is intended to support this class of
> 
>  certificates, but its scope is not limited to this application.?
> 
>  
> 
>  
> 
>  
> 
> 8. The text states in section 2 , Requirements and Assumptions.
> 
>  
> 
>     "Harmonization in the field of identity certificates issued to natural
> 
>     persons, in particular Qualified Certificates, is essential within
> 
>     several aspects that fall outside the scope of RFC 3280."
> 
>  
> 
> This sentence is using the term "identity certificate" instead of 
> "Qualified
> 
> certificate". This is in fact much better and it is unfortunate to use the
> 
> term "Qualified Certificate" everywhere within this document instead of
> 
> "Identity certificate". This sentence should be deleted, since it is
> 
> difficult to argue that harmonisation is essential without providing any 
> reason.
> 
>  
> 
> Reply
> 
> This text formulates a valid assumption that help defines the scope of 
> the standard. No reason to delete.
> 
>  
> 
> Proposed resolution:
> 
> No action
> 
>  
> 
>  
> 
> 9. The text states in section 2 , Requirements and Assumptions.
> 
>  
> 
> "The most important aspects that affect the scope of this specification
> 
> are:
> 
>  
> 
>     -  Definition of names and identity information in order to identify
> 
>        the associated subject in a uniform way."
> 
>  
> 
> What is the difference between a "name" and an "identity information" ?
> 
> Can a name identify a subject ? Not always.
> 
>  
> 
> Proposed rewording:
> 
>  
> 
> The most important aspects that affect the scope of this specification
> 
> are:
> 
>  
> 
>     -  Definition of attributes of the subject DN in order to name
> 
>        the associated subject in a uniform way."
> 
>  
> 
> Reply
> 
> Your clarification does not help. ?Denis Pinkas? is a name. Your place 
> of birth is not a name but still identity information. Some attributes 
> does not need to be part of the Subject DN.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 10. The text states in section 2 , Requirements and Assumptions.
> 
>  
> 
> "The most important aspects that affect the scope of this specification
> 
> are:
> 
>  
> 
>     -  Definition of information which identifies the CA and the
> 
>        jurisdiction under which the CA operates when issuing a particular
> 
>        certificate.
> 
>  
> 
> Qualified certificates (as meant by this document) are supposed to be
> 
> applicable for a "defined legal framework". What is the relationship with
> 
> the "jurisdiction under which the CA operates" ?
> 
>  
> 
> Qualified certificates (as meant by the EU Directive) identify the country
> 
> where the CA operates. While this has a well defined meaning, it seems
> 
> rather difficult to give a meaning to this statement outside the EU 
> Directive.
> 
>  
> 
> Proposed rewording:
> 
>  
> 
> "The most important aspects that affect the scope of this specification
> 
> are:
> 
>  
> 
>     -  Definition of information which identifies the country where
> 
>        the CA operates when issuing a certificate."
> 
>  
> 
> Reply
> 
> This is wrong. Country is not the only relevant denominator. State in US 
> can be equally relevant. The definitions in the context of the EU 
> context of this is handled in TS 101 862 where your issues already is 
> addressed. This standard gives the generic framework and is correct as 
> it is.
> 
>  
> 
> Proposed resolution:
> 
> No change.
> 
>  
> 
>  
> 
> 11. The text states in section 2 , Requirements and Assumptions.
> 
>  
> 
> "The most important aspects that affect the scope of this specification
> 
> are:
> 
>  
> 
>     -  Definition of a standardized way to store predefined statements
> 
>        with relevance for Qualified Certificates."
> 
>  
> 
> Delete: "with relevance for Qualified Certificates".
> 
>  
> 
> Reply
> 
> No, this has relevance for Qualified Certificates. This approach is also 
> used in the EU profile TS 101 862.
> 
>  
> 
> Proposed resolution:
> 
> No change.
> 
>  
> 
>  
> 
> 12. The text states in section 2.1 Properties:
> 
>  
> 
>     "This profile accommodates profiling needs for Qualified Certificates
> 
>     based on the assumptions that:
> 
>  
> 
>     -  Qualified Certificates are issued by a CA that makes a public
> 
>        statement that the certificate serves the purpose of a Qualified
> 
>        Certificate, as discussed in Section 2.2."
> 
>  
> 
> It is quite strange to mandate to make a public statement here.
> 
> Do we require a public statement when RFC 3280 compliant certificates
> 
> are issued ? To which of the sections would it mean compliance ?
> 
>  
> 
> Delete this item.
> 
>  
> 
> Reply
> 
> This is not stated as a requirement. This is stated as an assumption. 
> However I agree to remove the term ?public?.
> 
>  
> 
> Proposed resolution:
> 
> Keep text but remove ?public?.
> 
>  
> 
>  
> 
> 13. The text states in section 2.1 Properties:
> 
>  
> 
>     -  The Qualified Certificate indicates a certificate policy
> 
>        consistent with liabilities, practices and procedures undertaken
> 
>        by the CA, as discussed in Section 2.3."
> 
>  
> 
> There is no precise definition of such a certificate policy and precise
> 
> definitions are outside the scope of the PKIX WG.
> 
>  
> 
> Delete this item.
> 
>  
> 
> Reply
> 
> This standard provides directions of the use of certificate policies in 
> relation to qcStatement extension. This text is listed as one of the 
> justifying assumptions and is this relevant.
> 
>  
> 
> Proposed resolution:
> 
> No action
> 
>  
> 
>  
> 
> 14. The text states in section 2.1 Properties:
> 
>  
> 
>     -  The Qualified Certificate contains an identity based on a
> 
>        pseudonym or a real name of the subject.
> 
>  
> 
> No identity is ever contained in a certificate.
> 
>  
> 
> Proposed rewording:
> 
>  
> 
>     -  The Qualified Certificate contains a name which may be either
> 
>        based on the real name of the subject or a pseudonym."
> 
>  
> 
> Reply
> 
> Yes this is a good suggestion.
> 
>  
> 
> Proposed resolution:
> 
> Change text as proposed.
> 
>  
> 
>  
> 
> 15. The text states in section 2.2  Statement of Purpose
> 
>  
> 
>     "This profile defines two complementary ways to include this
> 
>     information:
> 
>  
> 
>     -  As information defined by a certificate policy included in the
> 
>        certificate policies extension, and
> 
>  
> 
>     -  As a statement included in the Qualified Certificates Statements
> 
>        extension."
> 
>  
> 
> As far as "EU Qualified Certificates" are concerned, the ways are not
> 
> "complementary", but "alternative".
> 
>  
> 
> Since no CP OID is being defined in the document to indicate this 
> "property"
> 
> (which is quite vague), this cannot be supported.
> 
>  
> 
> Since no statement is being defined in the document to indicate this
> 
> "property" (which is quite vague), this cannot be supported.
> 
>  
> 
> Please delete the whole section 2.2.
> 
>  
> 
> Reply
> 
> You are wrong here. The ways defined in TS 101 862 are complementary. 
> They are definitely not mutually exclusive. In fact the latest draft 
> strongly recommends both to be used at the same time since they serve 
> different purposes. Policy is the only mechanism that serves path 
> validation while the qcStatement supports programmatic detection of a QC 
> regardless of policy.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 16. The text states in section 2.3  Policy Issues
> 
>  
> 
>     "Certain policy aspects define the context in which this profile is to
> 
>     be understood and used.  It is however outside the scope of this
> 
>     profile to specify any policies or legal aspects that will govern
> 
>     services that issue or utilize certificates according to this
> 
>     profile."
> 
>  
> 
> Is it necessary to say that some other documents (please keep away "policy
> 
> aspects") whatever they are may use this document ? Isn't it the primary
> 
> goal of any standard ?
> 
>  
> 
> Please delete this paragraph.
> 
>  
> 
> Reply
> 
> This is a relevant part of the informative section 2. It is correct and 
> deleting it does not improve the standard. Note also that you previously 
> have agreed to this text in the RFC 3039 process.
> 
>  
> 
> Proposed resolution:
> 
> No change.
> 
>  
> 
>  
> 
> 17. The text states in section 2.3  Policy Issues:
> 
>  
> 
>     "It is however an underlying assumption in this profile that a
> 
>     responsible issuing CA will undertake to follow a publicly available
> 
>     certificate policy that is consistent with its liabilities, practices
> 
>     and procedures."
> 
>  
> 
> This assumption is not valid. Nothing will force a CA to adopt a publicly
> 
> available policy. Please delete this paragraph.
> 
>  
> 
> Reply
> 
> Agree to delete ?publicly available?, but the rest is relevant. Again 
> this is not a requirement section, just a list of scoping assumptions 
> justifying the profiling work in this standard.
> 
>  
> 
> Proposed resolution:
> 
> Remove ?publicly available?.
> 
>  
> 
>  
> 
> 18. The text states in section 2.4  Uniqueness of names
> 
>  
> 
>     ? An
> 
>     object can be assigned a distinguished name without being represented
> 
>     by an entry in the Directory, but this name is then the name its
> 
>     object entry could have had if it were represented in the Directory.
> 
>     In the context of qualified certificates, a distinguished name
> 
>     denotes a set of attribute values [X.501] which forms a name that is
> 
>     unambiguous within a certain domain that forms either a real or a
> 
>     virtual DIT (Directory Information Tree)[X.501].  In the case of
> 
>     subject names the domain is assumed to be at least the issuing domain
> 
>     of the CA.
> 
>  
> 
> These sentences do not help to understand the issue of uniqueness of names.
> 
> The fact that there is a real DIT or not is irrelevant. The notion of ?a
> 
> certain domain? and ?at least the issuing domain? is hazardous. Please
> 
> delete these sentences and keep the last sentence which is correct:
> 
>  
> 
>     ?The distinguished name MUST be unique for each subject
> 
>     entity certified by the one CA as defined by the issuer name field,
> 
>     during the whole life time of the CA.?
> 
>  
> 
> Reply
> 
> This was one of those texts that when through a lot of discussion and 
> changes in RFC 3039 before it ended up this way. This is why I didn?t 
> touch it. However, I agree to the change unless someone comes fourth and 
> motivates why the old text should be kept.
> 
>  
> 
> Proposed resolution:
> 
> Change as proposed.
> 
>  
> 
>  
> 
> 19. The text states in section 3.1.1  Issuer
> 
>  
> 
>     ?The identity of the issuer SHALL be specified using an appropriate
> 
>     subset of the following attributes:?
> 
>  
> 
> Please change ?identity? by ?DN?.
> 
>  
> 
> Reply
> 
> OK
> 
>  
> 
> Proposed resolution:
> 
> Change as proposed.
> 
>  
> 
>  
> 
> 20. The text states in section 3.1.1 Issuer :
> 
>  
> 
> ?Attributes present in the issuer field SHOULD be consistent with the laws
> 
> under which the issuer operates.?
> 
>  
> 
> We do not reference laws in other documents, but Certificate Policies
> 
> instead. Please refer to Certificate policies, and replace with:
> 
>  
> 
> ?Attributes present in the issuer field SHOULD be consistent with the
> 
> certificate policy of the certificate.?
> 
>  
> 
> Reply
> 
> Agree with your concern but not your proposed change. This statement is 
> redundant and handled in regional profiling where legal context can be 
> defined and referenced.
> 
>  
> 
> Proposed resolution:
> 
> Delete this sentence.
> 
>  
> 
>  
> 
> 21. The text states in section 3.1.1 Issuer :
> 
>  
> 
>     ?A relying party MAY have to consult associated certificate policies
> 
>     and/or the issuer's CPS, in order to determine the semantics of name
> 
>     fields and the laws under which the issuer operates.?
> 
>  
> 
> Please delete the end of the sentence, i.e. ?and the laws under which the
> 
> issuer operates?. There is no reason to refer to laws.
> 
>  
> 
> Reply
> 
> OK
> 
>  
> 
> Proposed resolution:
> 
> Delete as proposed
> 
>  
> 
>  
> 
> 22. The text states in section 3.1.2  Subject (page 8):
> 
>  
> 
> ?   Other attributes may be present but MUST NOT be necessary to
> 
>     distinguish the subject name from other subject names within the
> 
>     issuer domain.?
> 
>  
> 
> This sentence is wrong. The DN is uniquely global with all the attributes
> 
> present. Matching rules do not exclude some attributes. This sentence could
> 
> be interpreted as if a name matching rule could be constructed using only
> 
> these attributes and ignoring the additional ones. Please delete that 
> sentence.
> 
>  
> 
> Reply
> 
> The sentence still defines an important requirement that name uniqueness 
> must be maintained through these attributes. All relevant identity 
> matching scenarios aren?t limited to matching rules. However, 
> improvement suggested.
> 
>  
> 
> Proposed resolution:
> 
> New text.
> 
> ?Other attributes MAY also be present; however, the use of other
> 
> attributes MUST NOT be necessary to distinguish one subject
> 
> name from another subject names.  That is, the attributes listed
> 
> above are sufficient to ensure unique subject names.?
> 
>  
> 
>  
> 
> 23. The text states in section 3.1.2  Subject (pages 8 and 9):
> 
>  
> 
>        ?The surname and givenName attribute types SHALL, if present,
> 
>        contain the name of the subject, in accordance with the
> 
>        laws under which the CA prepares the certificate. These
> 
>        attributes SHALL be used in the subject field if the commonName
> 
>        attribute is not present. In cases where the subject only has a
> 
>        single name registered, the givenName attribute SHALL be used and
> 
>        the surname attribute SHALL be omitted.?
> 
>  
> 
> What is the ?registered name? of the subject ? Who is registering the name ?
> 
> Which laws is it ? Is it the laws where the CA operates ? Do all countries
> 
> have a law to say what is a registered name ? Please to not refer to
> 
> ?registered names? and national laws.
> 
>  
> 
>        ?The surname and givenName attribute types SHALL be used in the
> 
>        subject field if the commonName attribute is not present. In
> 
>        cases where the subject only has a givenName the surname attribute
> 
>        SHALL be omitted.?
> 
>  
> 
> Reply
> 
> Yes, your text is better. However there is an old error here that is 
> see, which you don?t address. givenName SHALL be used if neither 
> commonName nor PSEUDONYM is present. Update your text with that
> 
>  
> 
> Proposed resolution:
> 
> Change to:
> 
> ?The surname and givenName attribute types SHALL be used in the
> 
> subject field if neither the commonName attribute nor the pseudonym
> 
> attribute is present. In cases where the subject only has a
> 
> givenName the surname attribute SHALL be omitted.?
> 
>  
> 
>  
> 
> 24. The text states in section 3.2  Certificate Extensions:
> 
>  
> 
>     ?This specification provides additional details regarding the contents
> 
>     of five certificate extensions: Subject directory attributes,
> 
>     Certificate policies, Key usage, Biometric information and Qualified
> 
>     Certificate statements.?
> 
>  
> 
> This is not correct. It is not ?details regarding the content of five
> 
> certificate extensions?, but a profile for two basic fields, three existing
> 
> extensions and the definition of two new extensions.
> 
>  
> 
> Change with:
> 
>  
> 
>     ?This specification provides profiles for two fields: issuer and
> 
>     subject and for three certificate extensions: subject alternate
> 
>     name, subject directory attributes, and key usage. It also defines
> 
>     two extensions: biometric information and qualified certificate
> 
>     statements.?
> 
>  
> 
> Reply
> 
> The current text is not wrong but it can be made better.
> 
> You proposed text is however wrong because the new extensions are also 
> extensions. A new text is proposed also in response to comment 1.
> 
>  
> 
> We are not in agreement about deleting the policy extension but we are 
> in agreement with adding a subjectAltName extension section (see next 
> comment)
> 
>  
> 
> Proposed resolution:
> 
> ?This specification provides profiles for two certificate fields:
> 
> issuer and subject; it also provides profiles for four certificate
> 
> extensions defined in RFC 3280: subject alternate name, subject 
> directory attributes, certificate policies and key usage. This 
> specification defines two additional extensions: biometric information 
> and qualified certificate statements.?
> 
>  
> 
>  
> 
> 25. The text defines in section 3.2.1  Subject Directory Attributes. Why is
> 
> there no specification at all for the Subject Alternative Name ?
> 
>  
> 
> There should be a section saying that Internet electronic mail addresses
> 
> SHALL be placed there, if e-mail addresses need to be present.
> 
>  
> 
> Reply
> 
> Yes there should be a section for subjectAltName but not stating 
> anything about e-mail address. That is all handled in RFC 3280 and there 
> is no context defined in this standard where it is applicable to state 
> any further requirements. It is however relevant to make a short note 
> that placement of a DN in directoryName must follow the rules defined in 
> section 3.1.2.
> 
>  
> 
> Proposed resolution:
> 
> New section inserted.
> 
>  
> 
> ?3.2.1  Subject Alternative Name
> 
>  
> 
>     If the subjectAltName extension is present and it contains a
> 
>     directoryName name, then the directoryName MUST follow the
> 
>     conventions specified in section 3.1.2 of this profile.?
> 
>  
> 
>  
> 
> 26. The text states in section 3.2.2 Certificate Policies:
> 
>  
> 
>     ?Information provided by the issuer stating the purpose of the
> 
>     certificate as discussed in Section 2.2 SHOULD be evident through
> 
>     indicated policies.?
> 
>  
> 
> It is not evident from an OID to know what the certificate policy is about.
> 
> Since section 2.2 should be deleted, this sentence should be deleted as 
> well.
> 
>  
> 
> Reply
> 
> Since section 2.2 should be kept this should be kept as well. An OID 
> defines unambiguously a policy. If you know the policy then it is 
> evident from the OID what the policy is about.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 27. The text states in section 3.2.2 Certificate Policies:
> 
>  
> 
>     ?The certificate policies extension SHOULD include all policy
> 
>     information needed for validation of the certificate.?
> 
>  
> 
> The Certificate Policies extensions defines everything that is needed. 
> There
> 
> is nothing to be added here. Please delete that sentence.
> 
>  
> 
> Reply
> 
> The text is true but unclear. Propose new text rather than deletion. The 
> text is relevant to understand the relation between policy and use of 
> qcStatement.
> 
>  
> 
> Proposed resolution:
> 
> The certificate policies extension MUST include all policy information 
> needed for certification path validation.
> 
>  
> 
>  
> 
> 28. The text states in section 3.2.2 Certificate Policies:
> 
>  
> 
>     ?If policy information is included in the QCStatements extension
> 
>     (see 3.2.5), then this information SHOULD also be defined by
> 
>     indicated policies.?
> 
>  
> 
> QCStatements extension is still not described at this place when reading 
> the
> 
> document in sequence. This sentence is not relevant and could even be
> 
> misleading: QCStatements is not a direct alternative to a certificate
> 
> policy. It may indicate a conformity with a document where some parts of it
> 
> may be translated into a certificate policy. Please delete that sentence.
> 
>  
> 
> Reply
> 
> This text is relevant. It has previously proved to be relevant in the 
> update of TS 101 862 where we conclude that making qcStatements does not 
> free you from the obligatin to have a suitable policy that is sufficient 
> in its own. This also clarifies that qcStatement is NOT another form of 
> policy qualifier.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 29. It is very questionable why there should be a section 3.2.2 at all.
> 
> There is no additional specific constraints beyond what already exists in
> 
> RFC 3280. Please delete the whole section 3.2.2.
> 
>  
> 
> Reply
> 
> No, as described in previous comments.
> 
>  
> 
> Proposed resolution:
> 
> No change.
> 
>  
> 
>  
> 
> 30. The text states in section 3.2.3  Key Usage:
> 
>  
> 
>     ?The key usage extension SHALL be present. Key usage settings SHALL be
> 
>     set in accordance with RFC 3280 definitions. Further requirements on
> 
>     key usage settings MAY be defined by local policy and/or local legal
> 
>     requirements.?
> 
>  
> 
> The security consideration section states:
> 
>  
> 
>     ?Combining the nonRepudiation bit in the keyUsage certificate
> 
>     extension with other keyUsage bits may have security implications and
> 
>     this specification therefore recommends against such practices.?
> 
>  
> 
> This is quite true. However the main body of the document is lacking this
> 
> recommendation. The text that is currently in RFC 3039 should stay. It
> 
> should be adapted to avoid naming bit 1 as nonRepudiation since it is 
> likely
> 
> that the name of that bit will be changed by ISO. So speaking of bit 1 is
> 
> neutral and will be valid whatever the final name will be.
> 
>  
> 
> Please replace with:
> 
>  
> 
>     The key usage extension SHALL be present.  If the key usage bit 1
> 
>     is asserted then it SHOULD NOT be combined with any other key usage,
> 
>     i.e., if set, it SHOULD be set exclusively (see the security
> 
>     considerations section).
> 
>  
> 
> Reply
> 
> We have been through this in the WG and also in previous comments. No 
> change.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 31. The text states in section 3.2.3  Key Usage:
> 
>  
> 
>     ?The key usage extension MAY be marked critical.?
> 
>  
> 
> However, RFC 3280 states:
> 
>  
> 
>     ?When this extension appears, it SHOULD be marked critical.?
> 
>  
> 
> The ?MAY? should be changed into ?SHOULD?.
> 
>  
> 
> This leads to:
> 
>  
> 
>     ?The key usage extension SHOULD be marked critical.?
> 
>  
> 
> Reply
> 
> Correct.
> 
>  
> 
> Proposed resolution:
> 
> Change as proposed.
> 
>  
> 
>  
> 
> 32. The text states in section 3.2.5  Qualified Certificate Statements:
> 
>  
> 
>     ?A statement suitable for inclusion in this extension MAY be a
> 
>     statement by the issuer that the certificate is issued as a Qualified
> 
>     Certificate in accordance with a particular legal system (as
> 
>     discussed in Section 2.2).?
> 
>  
> 
> Providing examples before the actual definition of what is this 
> extension is
> 
> not appropriate. It should also be avoided to speak about ?legal systems?.
> 
> Please delete.
> 
>  
> 
> Reply
> 
> These are appropriate examples, reflecting real profiling work in ETSI 
> TS 101 862.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 33. The text states in section 3.2.5  Qualified Certificate Statements:
> 
>  
> 
>     ?Other statements suitable for inclusion in this extension MAY be
> 
>     statements related to the applicable legal jurisdiction within which
> 
>     the certificate is issued.  As an example this MAY include a maximum
> 
>     reliance limit for the certificate indicating restrictions on CA's
> 
>     liability.?
> 
>  
> 
> Providing examples before the actual definition of what is this 
> extension is
> 
> not appropriate. It should also be avoided to speak about ?legal
> 
> jurisdiction?. Please delete.
> 
>  
> 
> Reply
> 
> These are appropriate examples, reflecting real profiling work in ETSI 
> TS 101 862.
> 
>  
> 
> Proposed resolution:
> 
> No change
> 
>  
> 
>  
> 
> 34. The text states in section 3.2.5  Qualified Certificate Statements:
> 
>  
> 
>     ?This extension may be critical or non-critical.  If the extension is
> 
>     critical, this means that all statements included in the extension
> 
>     are regarded as critical.?
> 
>  
> 
> A note should be added after the ASN.1 description :
> 
>  
> 
> ?NOTE: This extension does not allow to mix critical and non-critical
> 
> Qualified Certificate Statements. Either all statements must be critical or
> 
> all statements must be non-critical.?
> 
>  
> 
> Reply
> 
> OK to add as ASN.1 comment
> 
>  
> 
> Proposed resolution:
> 
> Add Comment as ASN.1 comment text
> 
>  
> 
>  
> 
> 35. The text states in section 3.2.5.1 Predefined Statements:
> 
>  
> 
>     ?RFC 3039 defined one qualified certificate statement (id-qcs-
> 
>     pkixQCSyntax-v1), identifying conformance with syntax and semantics
> 
>     defined in RFC 3039.?
> 
>  
> 
> What means conformance with syntax and semantics ? Conformance clauses 
> means
> 
> that the SHALL statements have to be observed by the CA. From which 
> sections
> 
> should the SHALL statements be observed ? The document provides a profile
> 
> for two fields: issuer and subject, for one mandatory certificate
> 
> extensions: key usage and for two optional certificate extensions: subject
> 
> alternate name and subject directory attributes.
> 
>  
> 
> It means conformance with sections 3.1.1. Issuer, 3.1.2 subject, 3.2.3
> 
> key usage; if subject directory attributes is present, with section
> 
> 3.2.1.; and if subject alternate name attribute is present, with
> 
> section 3.2.X.
> 
>  
> 
> There is however a major problem: if RFC3039 is withdrawn, then there would
> 
> be no text to say what it means. So RFC 3039 cannot be withdrawn without
> 
> knowing first if someone as ever implemented id-qcs-pkixQCSyntax-v1.
> 
>  
> 
> Reply
> 
> If changed it?s then easier to just state compliance with section 3. 
> Section 3 contains all requirements.
> 
>  
> 
> Otherwise text regarding this is clarified in 04. It is relevant to 
> remain definition of the v1 OID but it is not to be included in new 
> certificates according to this profile.
> 
>  
> 
> Proposed resolution:
> 
> Replace ?syntax and semantics? with ?section 3?
> 
>  
> 
>  
> 
> 36. The text states in section 3.2.5.1 Predefined Statements:
> 
>  
> 
>     ?This profile includes a new qualified certificate statement
> 
>     (identified by the OID id-qcs-pkixQCSyntax-v2), identifying
> 
>     conformance with syntax and semantics defined in this profile.?
> 
>  
> 
> The sentence should be corrected in the following way:
> 
>  
> 
>     ?This profile includes a qualified certificate statement
> 
>     (identified by the OID id-qcs-pkixQCSyntax-v2), identifying
> 
>     conformance with sections 3.1.1. Issuer, 3.1.2 subject, 3.2.3 key
> 
>     usage ; if subject directory attributes is present, with section
> 
>     3.2.1.; and if subject alternate name attribute is present, with
> 
>     section 3.2.X.
> 
>  
> 
> Reply
> 
> Same reply as comment 35
> 
>  
> 
> Proposed resolution:
> 
> Fixed in accordance with comment 35
> 
>  
> 
>  
> 
> 37. The text states in section 3.2.5.1 Predefined Statements:
> 
>  
> 
>     ?This Qualified Certificate profile is referred to as version 2
> 
>     while RFC 3039 is referred to as version 1.?
> 
>  
> 
> This sentence cannot stay and will need to be fixed. See comment 35.
> 
>  
> 
> Reply
> 
> Fixed in draft 04
> 
>  
> 
> Proposed resolution:
> 
> No change to draft 04
> 
>  
> 
>  
> 
> 38. The European Directive on Electronic Signatures should be referenced in
> 
> the informative references section (section 5.2).
> 
>  
> 
> Reply
> 
> Agree
> 
>  
> 
> Proposed resolution:
> 
> Add Reference to directive (also stated in comment 2)
> 
>  
> 
>  
> 
>  
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JIvsWA072066; Thu, 19 Feb 2004 10:57:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1JIvsbq072065; Thu, 19 Feb 2004 10:57:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JIvr9J072057 for <[e-mail]>; Thu, 19 Feb 2004 10:57:53 -0800 (PST) (envelope-from [e-mail])
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i1JIvsk28004; Thu, 19 Feb 2004 10:57:54 -0800 (PST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3709 on Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 19 Feb 2004 10:57:54 -0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


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


        RFC 3709

        Title:      Internet X.509 Public Key Infrastructure:
                    Logotypes in X.509 Certificates
        Author(s):  S. Santesson, R. Housley, T. Freeman
        Status:     Standards Track
        Date:       February 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      21
        Characters: 46453
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-logotypes-13.txt

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


This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

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

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

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

RETRIEVE: rfc
DOC-ID: rfc3709

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

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

--OtherAccess--
--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1J5C9TW038086; Wed, 18 Feb 2004 21:12:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1J5C9xf038085; Wed, 18 Feb 2004 21:12:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av5-1-sn1.fre.skanova.net (av5-1-sn1.fre.skanova.net [81.228.11.111]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1J5C83K038036 for <[e-mail]>; Wed, 18 Feb 2004 21:12:09 -0800 (PST) (envelope-from [e-mail])
Received: by av5-1-sn1.fre.skanova.net (Postfix, from userid 502) id 2ED2E3AE8A; Wed, 18 Feb 2004 23:53:46 +0100 (CET)
Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av5-1-sn1.fre.skanova.net (Postfix) with ESMTP id 61FE53AE8C for <[e-mail]>; Wed, 18 Feb 2004 20:38:35 +0100 (CET)
Received: from arport (t12o913p66.telia.com [213.64.28.186]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 205C337E51; Wed, 18 Feb 2004 20:38:34 +0100 (CET)
Message-ID: <009401c3f655$f3b38f30$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
References: <[e-mail]><p06020405bc5684baadc0@[128.89.89.75]><001c01c3f4bb$8429a7d0$0500a8c0@arport><005601c3f52b$77192000$0500a8c0@arport><[e-mail]><01e401c3f570$70f4a790$0500a8c0@arport> <[e-mail]> <028701c3f577$34cc1850$0500a8c0@arport> <[e-mail]>
Subject: Re: TLS:  No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Date: Wed, 18 Feb 2004 20:32:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>but it is possible that TLS' client-auth
>>will not be used as most of the systems I have seen, rather use Java
>>applets for authentication.  This is due to the fact that the client-side
>>PKI in browsers is generally not that useful anyway, as browsers
>>cannot sign web content. 

>And again from my professional point of view, the java applet domain has 
>it's own problem, because it's just as difficult to get them to interact 
>with the locally available certificates.

>The java applet ends up using it's proprietary certificate store, so it 
>will only have the exact needed certificate(s). As a result, we don't 
>have to worry about sophisticated methods to choose the proper one.

>You end up with a one cert per application model, but this is not much 
>of interoperability and quite an obstacle to wider scale deployments.

Agreed.

But since digital signatures in browsers is not on any organizations
public agenda, Java is what we will deal with.   This excludes the 
standard client-side PKI support entirely as you cannot really have
two different crypto store systems (auth+sign).

So those who claim that Microsoft can't do crypto[1], don't worry,
CryptoAPI will soon do very little on the Internet w.r.t. clients certs.

Anders

1] I don't.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1I23fb2034280; Tue, 17 Feb 2004 18:03:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1I23fNT034279; Tue, 17 Feb 2004 18:03:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from center.kisa.or.kr ([211.252.150.11]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1I23dmK034273 for <[e-mail]>; Tue, 17 Feb 2004 18:03:39 -0800 (PST) (envelope-from [e-mail])
Received: from khoprivaio (localhost [127.0.0.1]) by center.kisa.or.kr (8.11.7p1+Sun/8.11.1) with ESMTP id i1I1uaL16512; Wed, 18 Feb 2004 10:56:36 +0900 (KST)
Message-Id: <[e-mail]>
From: "Jongwook Park" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Too Many Authors: draft-ietf-pkix-sim-02.txt
Date: Wed, 18 Feb 2004 11:03:36 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcP1unYQaY3Ifw7JSWqVG48GWJgZzAAA+jWA
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have already noticed that there are too many authors in the current draft.
But, a list of authors will be arranged in the next document.

Park.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Russ Housley
Sent: Wednesday, February 18, 2004 8:55 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Too Many Authors: draft-ietf-pkix-sim-02.txt


The maximum is five!  I do not know a good way to figure out who really
belongs....

The usual answer is to pick one or two "editors" and then add a Contributors
section to the document.

Russ

= = = = = = = = = =

PKIX Working Group                                   Jongwook Park(KISA)
Internet Draft                                          Jaeho Yoon(KISA)
Document: draft-ietf-pkix-sim-02.txt                  Seungjoo Kim(KISA)
Expires : August, 2004                              Sangjoon Park(BCQRE)
Target category: Standard Track                          Jaeil Lee(KISA)
                                                        Hongsub Lee(ISTF)
                                                          Polk, Tim(NIST)
                                                           February, 2004



                 Internet X.509 Public Key Infrastructure
                   Subject Identification Method (SIM)

                       <draft-ietf-pkix-sim-02.txt>







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1I2jQbP036382; Tue, 17 Feb 2004 18:45:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1I2jQ7Q036381; Tue, 17 Feb 2004 18:45:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1I2jPEO036375 for <[e-mail]>; Tue, 17 Feb 2004 18:45:25 -0800 (PST) (envelope-from [e-mail])
Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id E80E76D755 for <[e-mail]>; Tue, 17 Feb 2004 18:45:26 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "IETF-PKIX" <[e-mail]>
Subject: Comments on draft-ietf-pkix-sim-02.txt
Date: Tue, 17 Feb 2004 18:50:06 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
thread-index: AcP1qZXrVn3P/TG/QNK2kG6IhIOADgAHMujQ
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Gentlemen,

I have having a problem with the value of R.  There are a number of
apparently contradictory statements about it in this document.

-  In section 2.3 it states that Bob can get R from the PEPSI in the cert.
Put this is not actually published in the certificate.

-  In section 2.3 Alice computes H(Pa || R || SIItype || SII) but there is
no provision for passing R from the RA back to Alice.

-  The value of R is touted as the reason that Eve cannot do a good attack
against the PEPSI value, yet if R comes to Bob from the RA, there is no
reason for Eve not to ask for the same value from the RA.  If it comes from
Alice, then Alice needs to remember the value of R as well as the password
Pa.


Jim





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IGbjeH057700; Wed, 18 Feb 2004 08:37:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1IGbjWN057699; Wed, 18 Feb 2004 08:37:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IGbg9n057691 for <[e-mail]>; Wed, 18 Feb 2004 08:37:43 -0800 (PST) (envelope-from [e-mail])
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i1IGbQjP000634 for <[e-mail]>; Wed, 18 Feb 2004 11:37:26 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 18 Feb 2004 11:38:54 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Agenda Requests, Please...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

The PKIX WG will be meeting at the 59th IETF in Seoul on Monday, March 1 
3:30 - 5:30 PM.   I will be putting together the agenda for the PKIX WG 
over the next few days. I would like to receive all agenda requests by 
Monday morning at the latest. I will post the agenda to the WG that 
afternoon, and submit the official agenda Tuesday morning. WG activities 
will, as always, get preference for agenda time.

A side note:

I have been largely out of commission since late January, after fracturing 
one of my vertebrae.  This injury has severely limited my time in the 
office, so I am absolutely overwhelmed by email.  I just don't have the 
time to wade through it all.  In light of that:

	(1) Please put the word "Agenda" in the subject line! It helps me navigate 
through the
	spam and unread mail.

	(2) Please submit a new request *even if you sent me mail before*.   I 
will try searching
	for the usual key words, but am likely to miss old requests.

Thanks,

Tim Polk



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IE1Eex048393; Wed, 18 Feb 2004 06:01:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1IE1Es3048392; Wed, 18 Feb 2004 06:01:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IE1B0o048319 for <[e-mail]>; Wed, 18 Feb 2004 06:01:12 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 18 Feb 2004 14:58:44 +0100
Date: Wed, 18 Feb 2004 14:58:43 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: TLS: No policy OID. Was: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <028701c3f577$34cc1850$0500a8c0@arport>
References: <[e-mail]> <01e401c3f570$70f4a790$0500a8c0@arport> <028701c3f577$34cc1850$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <028701c3f577$34cc1850$0500a8c0@arport> on Tue, 17 Feb 2004 17:58:02 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> It really looks like client-side PKI is still in its
anders.rundgren> infancy.

Entirely depends on what you look at.  If you look at http thingies,
then yes, it seems like PKI has been mostly a server certificate
thingy (with a few exceptions, like SkandiaBanken that makes use of
client certificates).  However, if you look at things like S/MIME, you
see a lot more use of client certificates (you basically can't use
S/MIME without your own certificate).

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DMZwIQ025356; Fri, 13 Feb 2004 14:35:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1DMZwDK025355; Fri, 13 Feb 2004 14:35:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DMZv89025345 for <[e-mail]>; Fri, 13 Feb 2004 14:35:57 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1DMaEM9014474 for <[e-mail]>; Fri, 13 Feb 2004 17:36:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020407bc51b1353637@[128.89.89.75]>
Date: Fri, 13 Feb 2004 17:35:58 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: new WG item
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Alex Deacon sent a message to the list announcing the availability of 
a new, individual I-D tha proposes a nonceless profile for OCSP:

http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-00
.txt

Our AD (Russ) has indicated that since we are progressing OCSP to 
Draft standard, it is appropriate to bring this document into the WG 
at the same time, and consider it as well.  The first order of 
business is to decide first what the track is appropriate for the 
document, i.e., informational or standards track.  Then having 
decided on the context, the WG can discuss the document details.

Alex, please contact the Secretariat and ask that the I-D be moved 
under the PKIX umbrella.

Steve

P.S.  My initial observation arise that the word "only" frequently 
appears in the wrong place in sentences in the I-D.  Try moving it 
adjacent to the word being modified, e.g.,:

OCSPRequests conformant to this profile MUST only include one
     Request in the OCSPRequest.RequestList structure.

should be

OCSPRequests conformant to this profile MUST include only one
     Request in the OCSPRequest.RequestList structure.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DBjY1P088923; Fri, 13 Feb 2004 03:45:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1DBjYHU088922; Fri, 13 Feb 2004 03:45:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DBjSR0088911 for <[e-mail]>; Fri, 13 Feb 2004 03:45:32 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (csmail.cs.auckland.ac.nz [130.216.33.150]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 4E40434057 for <[e-mail]>; Sat, 14 Feb 2004 00:44:10 +1300 (NZDT)
Received: from 218-101-47-210.paradise.net.nz (218-101-47-210.paradise.net.nz [218.101.47.210]) by mail.cs.auckland.ac.nz (Horde) with HTTP for <[e-mail]>; Sat, 14 Feb 2004 00:45:43 +1300
Message-ID: <[e-mail]>
Date: Sat, 14 Feb 2004 00:45:43 +1300
From: Peter Gutmann <[e-mail]>
To: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-05.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Title : Internet X.509 Public Key Infrastructure -- Transport Protocols for CMP

Eeek, it's the return of the living dead.  Couldn't we just quietly pretend
this thing never existed and the only transport that did was HTTP?  Does
anyone actually still care about this, or is it just being recycled by a cron
job to keep it from being deleted?

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1D9LnD0065394; Fri, 13 Feb 2004 01:21:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1D9Lnf0065393; Fri, 13 Feb 2004 01:21:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1D9LkPZ065371 for <[e-mail]>; Fri, 13 Feb 2004 01:21:47 -0800 (PST) (envelope-from [e-mail])
Received: from ng171tdnot45.royalmail.com (unknown [144.87.146.19]) by mail4.consignia.com (Postfix) with ESMTP id AE4F7122AB8; Fri, 13 Feb 2004 09:22:02 +0000 (GMT)
Subject: Re: Policy OID => CP mapping (was: Policy User Interfaces)
To: "Anders Rundgren" <[e-mail]>
Cc: "Richard Levitte - VMS Whacker" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 13 Feb 2004 09:11:04 +0000
X-MIMETrack: Serialize by Router on m22ng32/H/MTANET(Release 6.5|September 26, 2003) at 13/02/2004 09:22:02
MIME-Version: 1.0
Content-type: multipart/alternative;  Boundary="0__=8FBBE4AADFA2C35D8f9e8a93df938690918c8FBBE4AADFA2C35D"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=8FBBE4AADFA2C35D8f9e8a93df938690918c8FBBE4AADFA2C35D
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable


Anders wrote:

> If I interpret AIA and SIA correctly I see absolutely
> nothing that looks like an OID =3D> CP function, only
> unspecified "repositories".

I know you're a fan of total automation, Anders, but if
a certificate is to be used as a strong trust mechanism and
not just a technology enabler then at some point the information
that it contains must link back to a legal mechanism in the
real world. IMO this is not something that can be automated,
as evidenced by the way AIA works. Even more, the evaluation
and acceptance of trust between businesses is something that
happens out-of-band. The people whose job it is to manage
interbusiness trust have to scrutinise the CP of the parties
with whom they are doing business electronically. To be frank,
once the CP has been accepted its incidental inclusion in each
signed transaction is technically irrelevant and only happens
for audit completeness and accountability.

Again my mind comes back to Policy Certificates which were
(are?) an attempt to automate the link between certificate
and liability that you are alluding to.

Chris

**********************************************************************
This email and any attachments are confidential and intended for the
addressee only. If you are not the named recipient, you must not use,
disclose, reproduce, copy or distribute the contents of this communicat=
ion.
If you have received this in error, please contact the sender and then
delete this email from your system.
**********************************************************************

=

--0__=8FBBE4AADFA2C35D8f9e8a93df938690918c8FBBE4AADFA2C35D
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body><font face=3D"Courier New">Anders wrote:</font><br>
<br>
<font face=3D"Courier New">&gt; If I interpret AIA and SIA correctly I =
see absolutely </font><br>
<font face=3D"Courier New">&gt; nothing that looks like an OID =3D&gt; =
CP function, only </font><br>
<font face=3D"Courier New">&gt; unspecified &quot;repositories&quot;.<b=
r>
</font><br>
<font face=3D"Courier New">I know you're a fan of total automation, And=
ers, but if</font><br>
<font face=3D"Courier New">a certificate is to be used as a strong trus=
t mechanism and </font><br>
<font face=3D"Courier New">not just a technology enabler then at some p=
oint the information </font><br>
<font face=3D"Courier New">that it contains must link back to a legal m=
echanism in the</font><br>
<font face=3D"Courier New">real world. IMO this is not something that c=
an be automated,</font><br>
<font face=3D"Courier New">as evidenced by the way AIA works. Even more=
, the evaluation </font><br>
<font face=3D"Courier New">and acceptance of trust between businesses i=
s something that </font><br>
<font face=3D"Courier New">happens out-of-band. The people whose job it=
 is to manage </font><br>
<font face=3D"Courier New">interbusiness trust have to scrutinise the C=
P of the parties </font><br>
<font face=3D"Courier New">with whom they are doing business electronic=
ally. To be frank, </font><br>
<font face=3D"Courier New">once the CP has been accepted its incidental=
 inclusion in each </font><br>
<font face=3D"Courier New">signed transaction is technically irrelevant=
 and only happens </font><br>
<font face=3D"Courier New">for audit completeness and accountability.</=
font><br>
<br>
<font face=3D"Courier New">Again my mind comes back to Policy Certifica=
tes which were</font><br>
<font face=3D"Courier New">(are?) an attempt to automate the link betwe=
en certificate</font><br>
<font face=3D"Courier New">and liability that you are alluding to.</fon=
t><br>
<br>
<font face=3D"Courier New">Chris</font><br>
<font face=3D"Courier New"><br>
</font><font face=3D"Courier New">*************************************=
*********************************<br>
</font><font face=3D"Courier New">This email and any attachments are co=
nfidential and intended for the addressee only. If you are not the name=
d recipient, you must not use, disclose, reproduce, copy or distribute =
the contents of this communication. If you have received this in error,=
 please contact the sender and then delete this email from your system.=
<br>
</font><font face=3D"Courier New">*************************************=
*********************************<br>
</font><font face=3D"Courier New"><br>
</font></body></html>=

--0__=8FBBE4AADFA2C35D8f9e8a93df938690918c8FBBE4AADFA2C35D--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CLHYmL066712; Thu, 12 Feb 2004 13:17:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CLHYOM066710; Thu, 12 Feb 2004 13:17:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1CLHXfG066702 for <[e-mail]>; Thu, 12 Feb 2004 13:17:33 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 2157 invoked by uid 0); 12 Feb 2004 21:17:48 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.67) by woodstock.binhost.com with SMTP; 12 Feb 2004 21:17:48 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 12 Feb 2004 16:15:06 -0500
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: clarification of CRL processing in RFC3280
In-Reply-To: <001501c3f196$49bce350$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh:

Thanks for filling in the missing detail.

Russ

At 01:30 PM 2/12/2004 -0500, Santosh Chokhani wrote:

>Russ:
>
>The proposal is to begin with the same TA issuer/subject name and not with
>the same key.
>
>The idea is to ensure that the two certification paths are for the same PKI
>hierarchy and the approach is workable.
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Russ Housley
>Sent: Thursday, February 12, 2004 10:07 AM
>To: [e-mail]; [e-mail]
>Subject: Re: clarification of CRL processing in RFC3280
>
>
>
>At 11:31 PM 2/11/2004 -0800, Julien Pierre wrote:
> >In section 6.3.3, (b) , RFC3280 states
> >
> >         (1)  If the DP includes cRLIssuer, then verify that the issuer
> >         field in the complete CRL matches cRLIssuer in the DP and that
> >         the complete CRL contains an issuing distribution point
> >         extension with the indrectCRL boolean asserted.  Otherwise,
> >         verify that the CRL issuer matches the certificate issuer.
> >
> >I am interested in a clarification of the "otherwise" case. What test
> >is
> >specifically intended to match the CRL issuer to the certificate issuer ?
>
>If Certificate.extensions.DistributionPoint.cRLIssuer is not present, then
>     Certificate.issuer MUST match CertificateList.issuer
>
> >(a). matching certificate
> >(b). matching subject
> >(c). some other entity matching test, and if so, which one ?
> >
> >It seems to me that (a) can't be the correct test, since even if
> >DP/IDPs
> >are not used, both the certificate being verified and the CRL can still
> >contain AuthorityKeyID extensions, therefore making the CRL issuer
> >certificate distinct from the certificate's issuer certificate.
>
>The same certificate is not required.  If this were required, then the CA
>would have a very difficult time rolling its signing key.  We need to allow
>the certificate to be signed by the 'old' key and the CRL to be signed by
>the 'new' key.
>
> >(b) seems like a good test to require. This is what NSS does today. But
> >I
> >can't help but think that it is not sufficient.
> >If only the issuer subject matches, then technically the CRL issuer
> >certificate and certificate issuer certificate could in fact be otherwise
> >totally different, even chaining to different roots. This would be similar
> >to the case of indirect CRLs, except without the proper extensions. Would
> >that be acceptable under RFC3280 ? Is there something else I'm missing,
> >perhaps name constraints, that would invalidate this case ? It seems to
> >invite some attacks, which I will describe once I know the answer to my
> >inquiry.
>
>Generally, they will be the same certificate.  When two different
>certificates are used, it should be die to the CA signing key being rolled
>over.  To this end, there has been discussion of also requiring the two
>certificates to terminate at the same trust anchor.  What if it is the
>trust anchor that is rolling over its signing key?
>
>Basically, it comes down to an old problem.  One needs to make sure that
>there cannot be two CAs operating with the same distinguished name.
>
> >(c) Hopefully this is the correct answer. Which is the more
> >comprehensive
> >matching test to be used in this case ?
>
>Answered above.
>
>Russ



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CLDAas066429; Thu, 12 Feb 2004 13:13:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CLDAik066428; Thu, 12 Feb 2004 13:13:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-1-sn1.fre.skanova.net (av7-1-sn1.fre.skanova.net [81.228.11.113]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CLD8uZ066416 for <[e-mail]>; Thu, 12 Feb 2004 13:13:09 -0800 (PST) (envelope-from [e-mail])
Received: by av7-1-sn1.fre.skanova.net (Postfix, from userid 502) id 6717937E69; Thu, 12 Feb 2004 22:13:22 +0100 (CET)
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by av7-1-sn1.fre.skanova.net (Postfix) with ESMTP id 4AF5737E61; Thu, 12 Feb 2004 22:13:22 +0100 (CET)
Received: from arport (t8o913p84.telia.com [213.64.26.204]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id i1CLDIIC012986; Thu, 12 Feb 2004 22:13:18 +0100 (CET)
Message-ID: <02d501c3f1ac$38679fd0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy OID => CP mapping (was: Policy User Interfaces)
Date: Thu, 12 Feb 2004 22:07:26 +0100
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_02D1_01C3F1B4.997AB930"; type="multipart/alternative"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_02D1_01C3F1B4.997AB930
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_02D2_01C3F1B4.997AB930"


------=_NextPart_001_02D2_01C3F1B4.997AB930
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Well,

If I interpret AIA and SIA correctly I see absolutely nothing that looks =
like an OID =3D> CP function, only unspecified "repositories".

That is, these extensions are impossible to use as the foundation for a =
streamlined, integrated policy management facility that would fit a =
modern operating system like W2K3 or something like that.

Further AIA goes upwards, while a useful object management =
administration facility works the other way.

In short this suxx, solves no problems, and is not worth CA's support.

Anders
  ----- Original Message -----=20
  From: [e-mail]=20
  To: Richard Levitte - VMS Whacker=20
  Cc: [e-mail]=20
  Sent: Thursday, February 12, 2004 17:30
  Subject: Re: Policy OID =3D> CP mapping (was: Policy User Interfaces)


  For me the mechanisms are there but they require the will of the =
issuer to=20
  comply with them. It all comes down to how seriously the issuer is =
about=20
  their product. A TTP that issues a high trust value certificate =
without exploiting=20
  (eg) AIA just isn't taking the whole thing seriously. Similarly, and =
end-user who=20
  is looking to trust a cert carrying (eg) AIA without looking up the =
level of liability=20
  acceptance contained therein is similarly negligent and deserves =
everything
  they get.

  The problem is, of course, that PKI use is inconsistent in the broader =
context
  and presently works well only in closed communities (as alluded to by =
another
  contributor earlier today). This is IMO partly deliberate design, =
partly through=20
  ignorance of how PKI works and partly through kludging to avoid known =
gaps.

  Chris

  Richard Levitte - VMS Whacker <[e-mail]>



      =20

                Richard Levitte - VMS Whacker <[e-mail]>
                Sent by: [e-mail]=20
                12/02/2004 14:46
      =20

        To: [e-mail]
        cc:=20
        Subject: Policy OID =3D> CP mapping (was: Policy User =
Interfaces)=20



  Guys,

  as part of this whole certificate policy discussion, there's one point
  that I'd like to take up where I haven't really seen a good solution:
  distribution of CPs. Yes, one can have a CPS URI and that can link
  further from there to the CP, or (*cough*) one might use a userNotice
  to point at the CP. Still, that's a fairly crude way to handle it,
  and some just don't. It would be a good thing if there was some
  formalised way to find a CP given a policy OID.

  I do not care what kind of technology would be used, if one would
  imagine finding CP pointers in LDAP, or via some contorted DNS RRs, or
  some new, entirely separate protocol (and no, I don't think
  Alvestrands object database, however nice it is to browse, is the
  solution :-)).

  Of course, some organizations may choose not to publish their CPs.
  Their choice, and maybe their loss, I couldn't care less. What I care
  about is that there seems to be no technical way at all to find the CP
  connected to a policy OID.

  As usual, if I'm misinformed, I'd love to stand corrected.

  -----
  Please consider sponsoring my work on free software.
  See http://www.free.lp.se/sponsoring.html for details.

  --
  Richard Levitte | http://richard.levitte.org/ | Tunnlandsv. 3
  Levitte Programming | http://www.lp.se/ | S-168 36 Bromma
  T: [phone] | | SWEDEN=20
      "Price, performance, quality... choose the two you like" =
********************************************************************** =
This email and any attachments are confidential and intended for the =
addressee only. If you are not the named recipient, you must not use, =
disclose, reproduce, copy or distribute the contents of this =
communication. If you have received this in error, please contact the =
sender and then delete this email from your system. =
********************************************************************** 
------=_NextPart_001_02D2_01C3F1B4.997AB930
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT face=3DArial size=3D2>Well,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>If I interpret AIA and SIA correctly I =
see=20
absolutely nothing that looks like an OID =3D&gt; CP function, only =
unspecified=20
"repositories".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>That is, these extensions are =
impossible to use as=20
the foundation for a streamlined, integrated policy management facility =
that=20
would fit a modern operating system like W2K3 or something like=20
that.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Further AIA goes upwards, while a =
useful object=20
management administration facility works the other way.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In short this suxx, solves no problems, =
and is not=20
worth CA's support.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail]=20
  =
href=3D"mailto:[e-mail]">[e-mail]</=
A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Richard Levitte - VMS Whacker</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, February 12, =
2004=20
  17:30</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Policy OID =3D&gt; =
CP mapping=20
  (was: Policy User Interfaces)</DIV>
  <DIV><BR></DIV>For me the mechanisms are there but they require the =
will of=20
  the issuer to <BR>comply with them. It all comes down to how seriously =
the=20
  issuer is about <BR>their product. A TTP that issues a high trust =
value=20
  certificate without exploiting <BR>(eg) AIA just isn't taking the =
whole thing=20
  seriously. Similarly, and end-user who <BR>is looking to trust a cert =
carrying=20
  (eg) AIA without looking up the level of liability <BR>acceptance =
contained=20
  therein is similarly negligent and deserves everything<BR>they =
get.<BR><BR>The=20
  problem is, of course, that PKI use is inconsistent in the broader=20
  context<BR>and presently works well only in closed communities (as =
alluded to=20
  by another<BR>contributor earlier today). This is IMO partly =
deliberate=20
  design, partly through <BR>ignorance of how PKI works and partly =
through=20
  kludging to avoid known gaps.<BR><BR>Chris<BR><BR><IMG height=3D16=20
  alt=3D"Inactive hide details for Richard Levitte - VMS Whacker =
<[e-mail]>"=20
  src=3D"cid:02cf01c3f1ac$37aba2d0$0500a8c0@arport" width=3D16>Richard =
Levitte - VMS=20
  Whacker &lt;[e-mail]&gt;<BR><BR><BR>
  <TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%" border=3D0 =
V5DOTBL=3D"true">
    <TBODY>
    <TR vAlign=3Dtop>
      <TD width=3D"1%"><IMG height=3D1 alt=3D""=20
        src=3D"cid:02d001c3f1ac$37aba2d0$0500a8c0@arport" width=3D72=20
border=3D0><BR></TD>
      <TD=20
      style=3D"BACKGROUND-IMAGE: =
url(cid:30__=[e-mail]); =
BACKGROUND-REPEAT: no-repeat"=20
      width=3D"1%"><IMG height=3D1 alt=3D""=20
        src=3D"cid:02d001c3f1ac$37aba2d0$0500a8c0@arport" width=3D220 =
border=3D0><BR>
        <UL>
          <UL>
            <UL>
              <UL><B><FONT size=3D2>Richard Levitte - VMS Whacker=20
                &lt;[e-mail]&gt;</FONT></B><BR><FONT size=3D2>Sent =
by:=20
                [e-mail]</FONT>=20
                <P><FONT size=3D2>12/02/2004 =
14:46</FONT></P></UL></UL></UL></UL></TD>
      <TD width=3D"100%"><IMG height=3D1 alt=3D""=20
        src=3D"cid:02d001c3f1ac$37aba2d0$0500a8c0@arport" width=3D1=20
        border=3D0><BR><FONT face=3DArial size=3D1></FONT><BR><FONT =
size=3D2>To:=20
        </FONT><FONT size=3D2>[e-mail]</FONT><BR><FONT =
size=3D2>cc:=20
        </FONT><BR><FONT size=3D2>Subject: </FONT><FONT size=3D2>Policy =
OID =3D&gt; CP=20
        mapping (was: Policy User=20
  Interfaces)</FONT></TD></TR></TBODY></TABLE><BR><BR><BR><FONT=20
  face=3D"Courier New">Guys,<BR></FONT><BR><FONT face=3D"Courier New">as =
part of=20
  this whole certificate policy discussion, there's one point<BR>that =
I'd like=20
  to take up where I haven't really seen a good =
solution:<BR>distribution of=20
  CPs. Yes, one can have a CPS URI and that can link<BR>further from =
there to=20
  the CP, or (*cough*) one might use a userNotice<BR>to point at the CP. =
Still,=20
  that's a fairly crude way to handle it,<BR>and some just don't. It =
would be a=20
  good thing if there was some<BR>formalised way to find a CP given a =
policy=20
  OID.<BR></FONT><BR><FONT face=3D"Courier New">I do not care what kind =
of=20
  technology would be used, if one would<BR>imagine finding CP pointers =
in LDAP,=20
  or via some contorted DNS RRs, or<BR>some new, entirely separate =
protocol (and=20
  no, I don't think<BR>Alvestrands object database, however nice it is =
to=20
  browse, is the<BR>solution :-)).<BR></FONT><BR><FONT face=3D"Courier =
New">Of=20
  course, some organizations may choose not to publish their =
CPs.<BR>Their=20
  choice, and maybe their loss, I couldn't care less. What I =
care<BR>about is=20
  that there seems to be no technical way at all to find the =
CP<BR>connected to=20
  a policy OID.<BR></FONT><BR><FONT face=3D"Courier New">As usual, if =
I'm=20
  misinformed, I'd love to stand corrected.<BR></FONT><BR><FONT=20
  face=3D"Courier New">-----<BR>Please consider sponsoring my work on =
free=20
  software.<BR>See </FONT><FONT face=3D"Courier New"><A=20
  =
href=3D"http://www.free.lp.se/sponsoring.html">http://www.free.lp.se/spon=
soring.html</A></FONT><FONT=20
  face=3D"Courier New"> for details.<BR></FONT><BR><FONT=20
  face=3D"Courier New">--<BR>Richard Levitte | </FONT><FONT =
face=3D"Courier New"><A=20
  =
href=3D"http://richard.levitte.org/">http://richard.levitte.org/</A></FON=
T><FONT=20
  face=3D"Courier New"> | Tunnlandsv. 3<BR>Levitte Programming | =
</FONT><FONT=20
  face=3D"Courier New"><A=20
  href=3D"http://www.lp.se/">http://www.lp.se/</A></FONT><FONT =
face=3D"Courier New">=20
  | S-168 36 Bromma<BR>T: [phone] | | SWEDEN</FONT>=20
  <UL>
    <UL><FONT face=3D"Courier New">"Price, performance, quality... =
choose the=20
      two you like"</FONT>=20
      =
**********************************************************************=20
      This email and any attachments are confidential and intended for =
the=20
      addressee only. If you are not the named recipient, you must not =
use,=20
      disclose, reproduce, copy or distribute the contents of this=20
      communication. If you have received this in error, please contact =
the=20
      sender and then delete this email from your system.=20
      =
**********************************************************************=20
  </UL></UL></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_02D2_01C3F1B4.997AB930--

------=_NextPart_000_02D1_01C3F1B4.997AB930
Content-Type: image/gif;
	name="graycol.gif"
Content-Transfer-Encoding: base64
Content-ID: <02cf01c3f1ac$37aba2d0$0500a8c0@arport>

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

------=_NextPart_000_02D1_01C3F1B4.997AB930
Content-Type: image/gif;
	name="ecblank.gif"
Content-Transfer-Encoding: base64
Content-ID: <02d001c3f1ac$37aba2d0$0500a8c0@arport>

R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7

------=_NextPart_000_02D1_01C3F1B4.997AB930--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CL3jDT065695; Thu, 12 Feb 2004 13:03:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CL3jIA065694; Thu, 12 Feb 2004 13:03:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CL3hpe065688 for <[e-mail]>; Thu, 12 Feb 2004 13:03:44 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 12 Feb 2004 22:04:00 +0100
Date: Thu, 12 Feb 2004 22:03:59 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Policy OID => CP mapping
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Thu, 12 Feb 2004 20:04:44 +0100 (CET), Richard Levitte - VMS Whacker <[e-mail]> said:

levitte> In message <[e-mail]> on Thu, 12 Feb 2004 16:30:15 +0000, [e-mail] said:
levitte> 
levitte> chris.gilbert> For me the mechanisms are there but they require the
levitte> chris.gilbert> will of the issuer to comply with them. It all comes
levitte> chris.gilbert> down to how seriously the issuer is about their
levitte> chris.gilbert> product. A TTP that issues a high trust value
levitte> chris.gilbert> certificate without exploiting (eg) AIA just isn't
levitte> chris.gilbert> taking the whole thing seriously. Similarly, and
levitte> chris.gilbert> end-user who is looking to trust a cert carrying (eg)
levitte> chris.gilbert> AIA without looking up the level of liability
levitte> chris.gilbert> acceptance contained therein is similarly negligent and
levitte> chris.gilbert> deserves everything they get.
levitte> 
levitte> I feel like such a fool.  Thanks for the reminder.

And now I've done some more thinking.  AIA (and SIA when applicable)
is a good thing, but not really what I asked for.  The thing I'd like
to see (and Anders too) is a 1-to-1 mapping between policy OID and
document.  I would like if there was a mechanism to fetch a document
given a policy OID.  The best example I can see is that the SIA can
have a URI for a CA repository (if given in a CA cert, for example),
and the page that leads to could contain a list of CP documents.

If there are reasons why a 1-to-1 mapping between OIDs and documents
wouldn't be needed, I'd like to hear them.  The goal here is for
software to be able to show the CP document fairly automagically upon
request when given a policy OID.

Note that this is *not* an argument for policy=CA.  Rather, it's a
request to solve what I see as a problem in policy OID usability,
which I'd rather do than have a kludge.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CKehMh063084; Thu, 12 Feb 2004 12:40:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CKehFA063083; Thu, 12 Feb 2004 12:40:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CKeeRA063074 for <[e-mail]>; Thu, 12 Feb 2004 12:40:41 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 12 Feb 2004 21:40:46 +0100
Date: Thu, 12 Feb 2004 21:40:46 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Policy OID => CP mapping
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <01a101c3f193$9625c4d0$0500a8c0@arport>
References: <[e-mail]> <01a101c3f193$9625c4d0$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <01a101c3f193$9625c4d0$0500a8c0@arport> on Thu, 12 Feb 2004 19:11:06 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Richard,
anders.rundgren> It is good to see that you have also found that the
anders.rundgren> administration of PKI suffers from some disconnects.
anders.rundgren> 
anders.rundgren> You have essentially two(2) basic ways of doing this:
anders.rundgren> 
anders.rundgren> 1) Define an extension that is put in EE-certificates
anders.rundgren>    that though requires that the administrator
anders.rundgren>    already is in possession of an EE-certificate.

The extension would probably be authorityInfoAccess.

anders.rundgren> 2) Define a CA/trust anchor-based extension that
anders.rundgren>    enables the thought functionality to also be used
anders.rundgren>    when only installing trust anchors, or viewing
anders.rundgren>    already installed such.  This is about going for
anders.rundgren>    the source of authority rather than adding yet
anders.rundgren>    another kludge to an already burdened scheme.

I believe the CA certificate could have a subjectInfoAccess extension
with such information, like a URI to the repository, where CPs and
CPSs could be stored, among others.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CJ4Zij056939; Thu, 12 Feb 2004 11:04:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CJ4ZgC056937; Thu, 12 Feb 2004 11:04:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CJ4XQY056929 for <[e-mail]>; Thu, 12 Feb 2004 11:04:33 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 12 Feb 2004 20:04:45 +0100
Date: Thu, 12 Feb 2004 20:04:44 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Policy OID => CP mapping
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Thu, 12 Feb 2004 16:30:15 +0000, [e-mail] said:

chris.gilbert> For me the mechanisms are there but they require the
chris.gilbert> will of the issuer to comply with them. It all comes
chris.gilbert> down to how seriously the issuer is about their
chris.gilbert> product. A TTP that issues a high trust value
chris.gilbert> certificate without exploiting (eg) AIA just isn't
chris.gilbert> taking the whole thing seriously. Similarly, and
chris.gilbert> end-user who is looking to trust a cert carrying (eg)
chris.gilbert> AIA without looking up the level of liability
chris.gilbert> acceptance contained therein is similarly negligent and
chris.gilbert> deserves everything they get.

I feel like such a fool.  Thanks for the reminder.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CInbvW055197; Thu, 12 Feb 2004 10:49:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CInaEo055196; Thu, 12 Feb 2004 10:49:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mxrelay23.treas.gov (mx-relay23.treas.gov [199.196.132.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CInZQC055190 for <[e-mail]>; Thu, 12 Feb 2004 10:49:35 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by mxrelay23.treas.gov (Postfix) with ESMTP id 855453B1; Thu, 12 Feb 2004 13:49:41 -0500 (EST)
Received: from mxrelay23.treas.gov ([127.0.0.1]) by localhost (mx-relay23 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10745-01-60; Thu, 12 Feb 2004 13:49:40 -0500 (EST)
Received: from tias24.treas.gov (tias-mailgw.treas.gov [199.196.132.24]) by mxrelay23.treas.gov (Postfix) with ESMTP id A9AAD3AF; Thu, 12 Feb 2004 13:49:40 -0500 (EST)
Received: from mailhub.treas.gov by tias24.treas.gov via smtpd (for [199.196.132.7]) with ESMTP; Thu, 12 Feb 2004 13:49:42 -0500
Received: from wdc2204.usmint.treas.gov ([127.0.0.1]) by mailhub-22.net.treas.gov (8.12.10/8.12.10) with ESMTP id i1CInpfF021741; Thu, 12 Feb 2004 13:49:51 -0500 (EST)
Received: by wdc2204.usmint.treas.gov with Internet Mail Service (5.5.2657.72) id <1LH0AMPC>; Thu, 12 Feb 2004 13:49:50 -0500
Message-ID: <[e-mail]>
From: "Key, Shawn (Contractor)" <[e-mail]>
To: "'Margus Freudenthal'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Policy User Interfaces
Date: Thu, 12 Feb 2004 13:49:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To all,

I am afraid I no longer have the need to be a "PKI lurker" as I have been
re-assigned to a different project. Although I find your e-mails to be
informative (for the most part ;), how can I unsubscribe from these e-mail
group lists, please? Thank you.

Regards,
Shawn

-----Original Message-----
From: Margus Freudenthal [mailto:[e-mail]]
Sent: Thursday, February 12, 2004 10:45 AM
To: [e-mail]; [e-mail]
Subject: Re: Policy User Interfaces



[e-mail] wrote:
> 
> > 1. add the "O=Foo Inc, OU=Kryptonium CA" root certificate among the
> > already installed ones.
> 
> > Not difference at all.
> 
> You missed out ...
> 
> 0. Spend a zillion groats deploying the Kryponium CA
> 
Even when using policies, you still have to create business process for
registering users and verifying that they really are worth the
kryptonium-level credit limit.

Adding an extra signing key for them should be minor problem, especially
assuming that you already have the necessary infrastructure (all the
minor level CA-s).


-- 
Margus



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CIUFeM053686; Thu, 12 Feb 2004 10:30:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CIUF2E053685; Thu, 12 Feb 2004 10:30:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CIUEQG053679 for <[e-mail]>; Thu, 12 Feb 2004 10:30:15 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i1CIUVjK025232 for <[e-mail]>; Thu, 12 Feb 2004 13:30:31 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: clarification of CRL processing in RFC3280
Date: Thu, 12 Feb 2004 13:30:22 -0500
Message-ID: <001501c3f196$49bce350$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i1CIUFQG053680
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ:

The proposal is to begin with the same TA issuer/subject name and not with
the same key.

The idea is to ensure that the two certification paths are for the same PKI
hierarchy and the approach is workable.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Russ Housley
Sent: Thursday, February 12, 2004 10:07 AM
To: [e-mail]; [e-mail]
Subject: Re: clarification of CRL processing in RFC3280



At 11:31 PM 2/11/2004 -0800, Julien Pierre wrote:
>In section 6.3.3, (b) , RFC3280 states
>
>         (1)  If the DP includes cRLIssuer, then verify that the issuer
>         field in the complete CRL matches cRLIssuer in the DP and that
>         the complete CRL contains an issuing distribution point
>         extension with the indrectCRL boolean asserted.  Otherwise,
>         verify that the CRL issuer matches the certificate issuer.
>
>I am interested in a clarification of the "otherwise" case. What test 
>is
>specifically intended to match the CRL issuer to the certificate issuer ?

If Certificate.extensions.DistributionPoint.cRLIssuer is not present, then
    Certificate.issuer MUST match CertificateList.issuer

>(a). matching certificate
>(b). matching subject
>(c). some other entity matching test, and if so, which one ?
>
>It seems to me that (a) can't be the correct test, since even if 
>DP/IDPs
>are not used, both the certificate being verified and the CRL can still 
>contain AuthorityKeyID extensions, therefore making the CRL issuer 
>certificate distinct from the certificate's issuer certificate.

The same certificate is not required.  If this were required, then the CA 
would have a very difficult time rolling its signing key.  We need to allow 
the certificate to be signed by the 'old' key and the CRL to be signed by 
the 'new' key.

>(b) seems like a good test to require. This is what NSS does today. But 
>I
>can't help but think that it is not sufficient.
>If only the issuer subject matches, then technically the CRL issuer 
>certificate and certificate issuer certificate could in fact be otherwise 
>totally different, even chaining to different roots. This would be similar 
>to the case of indirect CRLs, except without the proper extensions. Would 
>that be acceptable under RFC3280 ? Is there something else I'm missing, 
>perhaps name constraints, that would invalidate this case ? It seems to 
>invite some attacks, which I will describe once I know the answer to my 
>inquiry.

Generally, they will be the same certificate.  When two different 
certificates are used, it should be die to the CA signing key being rolled 
over.  To this end, there has been discussion of also requiring the two 
certificates to terminate at the same trust anchor.  What if it is the 
trust anchor that is rolling over its signing key?

Basically, it comes down to an old problem.  One needs to make sure that 
there cannot be two CAs operating with the same distinguished name.

>(c) Hopefully this is the correct answer. Which is the more 
>comprehensive
>matching test to be used in this case ?

Answered above.

Russ 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CIGmmp052582; Thu, 12 Feb 2004 10:16:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CIGmR5052581; Thu, 12 Feb 2004 10:16:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av9-1-sn1.fre.skanova.net (av9-1-sn1.fre.skanova.net [81.228.11.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CIGlM6052567 for <[e-mail]>; Thu, 12 Feb 2004 10:16:47 -0800 (PST) (envelope-from [e-mail])
Received: by av9-1-sn1.fre.skanova.net (Postfix, from userid 502) id 3EB8237E6B; Thu, 12 Feb 2004 19:17:00 +0100 (CET)
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by av9-1-sn1.fre.skanova.net (Postfix) with ESMTP id 2B6EE37E6B; Thu, 12 Feb 2004 19:17:00 +0100 (CET)
Received: from arport (t9o913p71.telia.com [213.64.27.71]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id i1CIGwIC009956; Thu, 12 Feb 2004 19:16:59 +0100 (CET)
Message-ID: <01a101c3f193$9625c4d0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Richard Levitte - VMS Whacker" <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy OID => CP mapping (was: Policy User Interfaces)
Date: Thu, 12 Feb 2004 19:11:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard,
It is good to see that you have also found that the administration
of PKI suffers from some disconnects.

You have essentially two(2) basic ways of doing this:

1) Define an extension that is put in EE-certificates that
though requires that the administrator already is in possession
of an EE-certificate.

2) Define a CA/trust anchor-based extension that enables the
thought functionality to also be used when only installing trust
anchors, or viewing already installed such.  This is about
going for the source of authority rather than adding yet another
kludge to an already burdened scheme.

Anders


----- Original Message ----- 
From: "Richard Levitte - VMS Whacker" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, February 12, 2004 15:46
Subject: Policy OID => CP mapping (was: Policy User Interfaces)



Guys,

as part of this whole certificate policy discussion, there's one point
that I'd like to take up where I haven't really seen a good solution:
distribution of CPs.  Yes, one can have a CPS URI and that can link
further from there to the CP, or (*cough*) one might use a userNotice
to point at the CP.  Still, that's a fairly crude way to handle it,
and some just don't.  It would be a good thing if there was some
formalised way to find a CP given a policy OID.

I do not care what kind of technology would be used, if one would
imagine finding CP pointers in LDAP, or via some contorted DNS RRs, or
some new, entirely separate protocol (and no, I don't think
Alvestrands object database, however nice it is to browse, is the
solution :-)).

Of course, some organizations may choose not to publish their CPs.
Their choice, and maybe their loss, I couldn't care less.  What I care
about is that there seems to be no technical way at all to find the CP
connected to a policy OID.

As usual, if I'm misinformed, I'd love to stand corrected.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CH0uQN046314; Thu, 12 Feb 2004 09:00:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CH0uI7046313; Thu, 12 Feb 2004 09:00:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-2-sn1.fre.skanova.net (av7-2-sn1.fre.skanova.net [81.228.11.114]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CH0tTc046306 for <[e-mail]>; Thu, 12 Feb 2004 09:00:55 -0800 (PST) (envelope-from [e-mail])
Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id 291B537EB4; Thu, 12 Feb 2004 18:01:08 +0100 (CET)
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id 1872937E7B; Thu, 12 Feb 2004 18:01:08 +0100 (CET)
Received: from arport (t11o913p74.telia.com [213.64.28.74]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id i1CH15IC029825; Thu, 12 Feb 2004 18:01:05 +0100 (CET)
Message-ID: <015501c3f188$fc0ecae0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <017201c3f14b$16b6b620$0500a8c0@arport>            <[e-mail]>            <001c01c3f166$ba19b130$0500a8c0@arport> <[e-mail]>
Subject: Re: Policy User Interfaces
Date: Thu, 12 Feb 2004 17:55:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard,

Although technically possible, this use case does not match the
"VeriSign-like" scenarios I refer to.  They are about identity
and hardly anything else.

I also consider this way of stuffing certificates with potentially
dynamic information as unrealistic as credit-limit is a lookup
mechanism in most real-world scenarios.

If OTOH policies are rather used to indicate usage, security-
level etc. the administration of every unique Policy OID
will require the same care as the installation of a single
policy trust anchor.  But with more fuzz:

 1. the policy=CA scenario: install the "O=Foo Inc, OU=Platinum CA"
    root certificate.

 2. the multi-policy CA scenario: install the "O=Foo Inc, OU=CA" root
    certificate AND the policy OID corresponding to Platinum.

The Policy OID must be read in the CP and pasted into an
application specific dialog or command line as few existing
key admin tools supports this.  As do few trust store mechanisms
either which creates even more fuzz as the integrity of the trust
database is dependent on two *disjunct* systems.  Unless MSFT
and SUN augment their trust store mechanisms with policy OID
support, I remain highly skeptical about their commitment to
the policy OID system.  Outside of the PKIX list that is...

Anders

----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, February 12, 2004 15:15
Subject: Re: Policy User Interfaces


In message <001c01c3f166$ba19b130$0500a8c0@arport> on Thu, 12 Feb 2004 13:49:39 +0100, "Anders Rundgren" <[e-mail]>
said:

anders.rundgren> Here you "policy-OID-zealots" lose me completely.

Hmm, that's the first time I've been called a zealot.  Is that good or
bad?  :-)

anders.rundgren> Assume that you are in the situation where you have
anders.rundgren> to decide whether you are going to accept a new trust
anders.rundgren> anchor or not.  Then you [maybe] read the CP and make
anders.rundgren> the decision to "trust" this and installs the trusts
anders.rundgren> anchor.  If the trust anchor represents a single
anders.rundgren> policy CA, you don't have to bother about anything
anders.rundgren> more.

Hmm.  An example: say there's a business that deals with fairly
expensive stuff, and will therefore only deal with people that can
show they have a minimum credit limit of $100k.  They can verify
certain certificates that correspond to the Silver ($10k limit),
Gold ($100k limit) and Platinum ($1M limit) policies.  To have their
software work with this, they need to configure it with information on
what kind of data is acceptable.  As far as I can see, here's how they
would handle it:

 1. the policy=CA scenario: install the "O=Foo Inc, OU=Platinum CA"
    and "O=Foo Inc, OU=Gold CA" root certificates.
 2. the multi-policy CA scenario: install the "O=Foo Inc, OU=CA" root
    certificate and the policy OIDs corresponding to Gold and
    Platinum.

Not much of a difference, really.  Now, suppose Foo Inc adds a
Kryptonium policy with a $10M credit limit.  Of course, our example
business wants to include people with that kind of credit policy among
their customers (they would hardly say "you have too high a limit, so
we can't trust you").  To do that, they would have to perform one of
the following actions:

 1. add the "O=Foo Inc, OU=Kryptonium CA" root certificate among the
    already installed ones.
 2. add the Kryptonium policy OID among the already installed policy
    OIDs.

Not difference at all.  After all, to do this at all, they have to be
informed, one way or another, that there's a new policy and what
pieces of data come with it.  And either way, don't you think that our
example business would like to know the conditions applied to the new
policy, i.e. read some kind of policy document?  How are things like
this handled with credit cards today?  Am I about to be desillusioned?

I really don't understand how the scenarios above would be performed
without some kind of human action and awareness.  I doubt "magic" is
an appropriate response...

anders.rundgren> >And if you're thinking of just having an increasing
anders.rundgren> >list of roots in your software, just think how
anders.rundgren> >hellish it will be for *every* user or administrator
anders.rundgren> >everytime a new CA pops up just because some company
anders.rundgren> >sets up a new policy.
anders.rundgren>
anders.rundgren> This is based on the rather speculative idea that CAs
anders.rundgren> add policies at their wim.  But if policies are NOT
anders.rundgren> standardized users still get the very same problem:
anders.rundgren> a blocked communication channel.

Uhmm, I wasn't really implying "at their wim", but you can't really
deny that policy changes and additions DO happen, and when that
happens, there is some new information that you will need to deal with
if you want to bother with the changes or additions at all.

anders.rundgren> This is what makes people REALLY upset and RIGHTFULLY
anders.rundgren> wanting that userid/password stuff back, as it had no
anders.rundgren> legal issues, no policy "crap", and you can just
anders.rundgren> phone it to the other guy.

Are you talking about people like users or people like business
administrators?  I can fully understand that your regular J. Random
User doesn't give a crap about policies more than possibly the pamflet
he gets to read when he got his brand new credit card (most people do
not read that either).  I don't expect J. Random User to check the
policies that come with the certificate served by https://foo.com/.
However, if Random Bank Inc does business with all kinds of customers
and use the customers' client certificate for authentication and other
checks, I would be *really* surprised if they wouldn't want to know
what credit limits come with those.  Things like credit limits would,
as far as I can see, come as part of the certificate policy in those
client certificates.  I'm quite sure that bank *does* care about such
stuff.

Of course, the bank example requires either that they have done a bit
of cross certification with credit companies or other banks, or that
their customers all have certificates issued by said bank.

But of course, that bank can as well use userid/password and have the
rest in a database.  It's all part of what you believe in and if you
want to be able to use information coming from other sources or not.

anders.rundgren> I believe this situation will limit the applicability
anders.rundgren> of multi-policy CAs considerably.

I think that your scenario may limit the applicability of X.509/PKIX
at all, just as much as multi-policy CAs.

anders.rundgren> Agreeably, I work with open scenarios where
anders.rundgren> competence is zero or below.  It is challenging in
anders.rundgren> its own mysterious ways...

Now, *that* is something I agree with, and I do believe that those of
us that feel they have enough competence have a more or less implied
role as educators.  Of course, one has to be willing to educate in the
first place...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CGW2EL044393; Thu, 12 Feb 2004 08:32:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CGW2Bc044392; Thu, 12 Feb 2004 08:32:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CGW0tt044384 for <[e-mail]>; Thu, 12 Feb 2004 08:32:01 -0800 (PST) (envelope-from [e-mail])
Received: from ng171tdnot45.royalmail.com (unknown [144.87.146.19]) by mail3.consignia.com (Postfix) with ESMTP id 839401C18E6; Thu, 12 Feb 2004 16:32:16 +0000 (GMT)
Subject: Re: Policy OID => CP mapping (was: Policy User Interfaces)
To: Richard Levitte - VMS Whacker <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 12 Feb 2004 16:30:15 +0000
X-MIMETrack: Serialize by Router on m22ng32/H/MTANET(Release 6.5|September 26, 2003) at 12/02/2004 16:32:16
MIME-Version: 1.0
Content-type: multipart/related;  Boundary="0__=8FBBE4ABDFCA19078f9e8a93df938690918c8FBBE4ABDFCA1907"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=8FBBE4ABDFCA19078f9e8a93df938690918c8FBBE4ABDFCA1907
Content-type: multipart/alternative; 
	Boundary="1__=8FBBE4ABDFCA19078f9e8a93df938690918c8FBBE4ABDFCA1907"

--1__=8FBBE4ABDFCA19078f9e8a93df938690918c8FBBE4ABDFCA1907
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable


For me the mechanisms are there but they require the will of the issuer=
 to
comply with them. It all comes down to how seriously the issuer is abou=
t
their product. A TTP that issues a high trust value certificate without=

exploiting
(eg) AIA just isn't taking the whole thing seriously. Similarly, and
end-user who
is looking to trust a cert carrying (eg) AIA without looking up the lev=
el
of liability
acceptance contained therein is similarly negligent and deserves everyt=
hing
they get.

The problem is, of course, that PKI use is inconsistent in the broader
context
and presently works well only in closed communities (as alluded to by
another
contributor earlier today). This is IMO partly deliberate design, partl=
y
through
ignorance of how PKI works and partly through kludging to avoid known g=
aps.

Chris



                                                                       =
                                                                 
                      Richard Levitte -                                =
                                                                 
                      VMS Whacker               To:      ietf-pkix@imc.=
org                                                              
                      <[e-mail]>           cc:                    =
                                                                 
                      Sent by:                  Subject: Policy OID =3D=
> CP mapping (was: Policy User Interfaces)                         
                      owner-ietf-pkix@m                                =
                                                                 
                      ail.imc.org                                      =
                                                                 
                                                                       =
                                                                 
                                                                       =
                                                                 
                      12/02/2004 14:46                                 =
                                                                 
                                                                       =
                                                                 
                                                                       =
                                                                 





Guys,

as part of this whole certificate policy discussion, there's one point
that I'd like to take up where I haven't really seen a good solution:
distribution of CPs.  Yes, one can have a CPS URI and that can link
further from there to the CP, or (*cough*) one might use a userNotice
to point at the CP.  Still, that's a fairly crude way to handle it,
and some just don't.  It would be a good thing if there was some
formalised way to find a CP given a policy OID.

I do not care what kind of technology would be used, if one would
imagine finding CP pointers in LDAP, or via some contorted DNS RRs, or
some new, entirely separate protocol (and no, I don't think
Alvestrands object database, however nice it is to browse, is the
solution :-)).

Of course, some organizations may choose not to publish their CPs.
Their choice, and maybe their loss, I couldn't care less.  What I care
about is that there seems to be no technical way at all to find the CP
connected to a policy OID.

As usual, if I'm misinformed, I'd love to stand corrected.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"




     ******************************************************************=
****
     This email and any attachments are confidential and intended for t=
he
     addressee only. If you are not the named recipient, you must not u=
se,
     disclose, reproduce, copy or distribute the contents of this
     communication. If you have received this in error, please contact =
the
     sender and then delete this email from your system.
     ******************************************************************=
****

=

--1__=8FBBE4ABDFCA19078f9e8a93df938690918c8FBBE4ABDFCA1907
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body>For me the mechanisms are there but they require the will o=
f the issuer to <br>
comply with them. It all comes down to how seriously the issuer is abou=
t <br>
their product. A TTP that issues a high trust value certificate without=
 exploiting <br>
(eg) AIA just isn't taking the whole thing seriously. Similarly, and en=
d-user who <br>
is looking to trust a cert carrying (eg) AIA without looking up the lev=
el of liability <br>
acceptance contained therein is similarly negligent and deserves everyt=
hing<br>
they get.<br>
<br>
The problem is, of course, that PKI use is inconsistent in the broader =
context<br>
and presently works well only in closed communities (as alluded to by a=
nother<br>
contributor earlier today). This is IMO partly deliberate design, partl=
y through <br>
ignorance of how PKI works and partly through kludging to avoid known g=
aps.<br>
<br>
Chris<br>
<br>
<img src=3D"cid:10__=[e-mail]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for Richard Levitte - V=
MS Whacker &lt;[e-mail]&gt;">Richard Levitte - VMS Whacker &lt;lev=
[e-mail]&gt;<br>
<br>
<br>

<table V5DOTBL=3Dtrue width=3D"100%" border=3D"0" cellspacing=3D"0" cel=
lpadding=3D"0">
<tr valign=3D"top"><td width=3D"1%"><img src=3D"cid:20__=3D8FBBE4ABDFCA=
[e-mail]" border=3D"0" height=3D"1" width=3D"72" al=
t=3D""><br>
</td><td style=3D"background-image:url(cid:30__=3D8FBBE4ABDFCA19078f9e8=
[e-mail]); background-repeat: no-repeat; " width=3D"1%"><img=
 src=3D"cid:20__=[e-mail]" border=3D"=
0" height=3D"1" width=3D"220" alt=3D""><br>

<ul>
<ul>
<ul>
<ul><b><font size=3D"2">Richard Levitte - VMS Whacker &lt;[e-mail]=
&gt;</font></b><br>
<font size=3D"2">Sent by: [e-mail]</font>
<p><font size=3D"2">12/02/2004 14:46</font></ul>
</ul>
</ul>
</ul>
</td><td width=3D"100%"><img src=3D"cid:20__=3D8FBBE4ABDFCA19078f9e8a93=
[e-mail]" border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
<font size=3D"1" face=3D"Arial">	</font><br>
<font size=3D"2">	To:	</font><font size=3D"2">[e-mail]</font><=
br>
<font size=3D"2">	cc:	</font><br>
<font size=3D"2">	Subject:	</font><font size=3D"2">Policy OID =3D&gt; C=
P mapping (was: Policy User Interfaces)</font></td></tr>
</table>
<br>
<br>
<br>
<font face=3D"Courier New">Guys,<br>
</font><br>
<font face=3D"Courier New">as part of this whole certificate policy dis=
cussion, there's one point<br>
that I'd like to take up where I haven't really seen a good solution:<b=
r>
distribution of CPs.  Yes, one can have a CPS URI and that can link<br>=

further from there to the CP, or (*cough*) one might use a userNotice<b=
r>
to point at the CP.  Still, that's a fairly crude way to handle it,<br>=

and some just don't.  It would be a good thing if there was some<br>
formalised way to find a CP given a policy OID.<br>
</font><br>
<font face=3D"Courier New">I do not care what kind of technology would =
be used, if one would<br>
imagine finding CP pointers in LDAP, or via some contorted DNS RRs, or<=
br>
some new, entirely separate protocol (and no, I don't think<br>
Alvestrands object database, however nice it is to browse, is the<br>
solution :-)).<br>
</font><br>
<font face=3D"Courier New">Of course, some organizations may choose not=
 to publish their CPs.<br>
Their choice, and maybe their loss, I couldn't care less.  What I care<=
br>
about is that there seems to be no technical way at all to find the CP<=
br>
connected to a policy OID.<br>
</font><br>
<font face=3D"Courier New">As usual, if I'm misinformed, I'd love to st=
and corrected.<br>
</font><br>
<font face=3D"Courier New">-----<br>
Please consider sponsoring my work on free software.<br>
See </font><font face=3D"Courier New"><a href=3D"http://www.free.lp.se/=
sponsoring.html">http://www.free.lp.se/sponsoring.html</a></font><font =
face=3D"Courier New"> for details.<br>
</font><br>
<font face=3D"Courier New">--<br>
Richard Levitte     | </font><font face=3D"Courier New"><a href=3D"http=
://richard.levitte.org/">http://richard.levitte.org/</a></font><font fa=
ce=3D"Courier New"> | Tunnlandsv. 3<br>
Levitte Programming | </font><font face=3D"Courier New"><a href=3D"http=
://www.lp.se/">http://www.lp.se/</a></font><font face=3D"Courier New"> =
          | S-168 36 Bromma<br>
T: [phone] |                             | SWEDEN</font>
<ul>
<ul><font face=3D"Courier New">&quot;Price, performance, quality...  ch=
oose the two you like&quot;</font>



**********************************************************************
This email and any attachments are confidential and intended for the ad=
dressee only. If you are not the named recipient, you must not use, dis=
close, reproduce, copy or distribute the contents of this communication=
. If you have received this in error, please contact the sender and the=
n delete this email from your system.
**********************************************************************


</ul>
</ul>
</body></html>=


--1__=8FBBE4ABDFCA19078f9e8a93df938690918c8FBBE4ABDFCA1907--


--0__=8FBBE4ABDFCA19078f9e8a93df938690918c8FBBE4ABDFCA1907
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <10__=[e-mail]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4ABDFCA19078f9e8a93df938690918c8FBBE4ABDFCA1907
Content-type: image/gif; 
	name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <20__=[e-mail]>
Content-transfer-encoding: base64

R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7

--0__=8FBBE4ABDFCA19078f9e8a93df938690918c8FBBE4ABDFCA1907--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CGFUWd042904; Thu, 12 Feb 2004 08:15:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CGFUvV042903; Thu, 12 Feb 2004 08:15:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CGFTgN042892 for <[e-mail]>; Thu, 12 Feb 2004 08:15:29 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 12 Feb 2004 11:15:41 -0500
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Policy User Interfaces
References: <[e-mail]> <017201c3f14b$16b6b620$0500a8c0@arport>
In-Reply-To: <017201c3f14b$16b6b620$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Competitive enterprises have been known to cooperate
and agree on standards, both commercially-developed
(Beta / VHS / MiniDV / DVD-RW / DVD+RW / DVD-RAM for
video, 802.11b / 802.11g for wireless networking)
and government-sponsored (FIPS 140-2 Level 1/2/3/4
for crypto modules, 87/89/91 octane for gasoline).
Joe Sixpack doesn't need to understand the technical
details on any of these standards; he just needs
to know what media is compatible with his player
or what gas is compatible with his car.  That's the
point of standards.

Certificate Policy can be both business-defined and
standardized; they are not mutually exclusive.  All
that is required is for an initial coalition of vendors
to demonstrate competitive advantage by standardizing.
Additional vendors will then either join the first
camp or form other camps.   Or, more likely, the
catalyst for standardization will be government or
commercial certificate consumers (automobile, aerospace,
etc) rather than certificate producers.

Either way, policy standardization isn't going to be
justified by looking at one vendor and comparing the
effort to stand up one CA vs. (for example) four.
The leverage only happens when you look at four
community-developed policies and have N >> 4
independent vendors sign on to support (either
directly or via policy mapping) them.

Is this a dream?  Maybe.

Is it "policy zealotry"?   Of course not, but feel
free to call it what you wish.  It looks more like
"vision" or "leadership" to me.

Dave




Anders Rundgren wrote:

> So you really mean that there WILL be a LIMITED SET of
> UNIVERSALLY globally accepted policy OIDs that effectively
> replaces CP documents?  And COTS application will be
> pre-programmed accordingly?
> 
> If this interpretation is correct I can only say: Dream on.
> 
> My "dreams" are based on the fact vendors SHOULD NEVER
> *have* to agree on things they consider "their own business".  Policy is
> definitely (unless the UN is involved), community or business defined.
> 
> And there are MANY communities and businesses!
> 
> This is why the policy system [on a wider scale] is likely
> to end-up as the global X.500 directory, as a "vision".
> 
> This is also why I insist recommending single-policy CAs
> as they are independent of  "dreams" and "visions", they just
> work.  Albeit at a premium for the owner.
> 
> Anders
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CGBgsb042545; Thu, 12 Feb 2004 08:11:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CGBgGA042544; Thu, 12 Feb 2004 08:11:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CGBfev042538 for <[e-mail]>; Thu, 12 Feb 2004 08:11:41 -0800 (PST) (envelope-from [e-mail])
Received: from orionsec.com (localhost [127.0.0.1]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i1CGBrjK001281; Thu, 12 Feb 2004 11:11:54 -0500
From: "Santosh Chokhani" <[e-mail]>
To: Stephen Kent <[e-mail]>, "Santosh Chokhani" <[e-mail]>
CC: <[e-mail]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Date: Thu, 12 Feb 2004 12:11:53 -0400
Message-Id: <[e-mail]>
In-Reply-To: <p06020401bc514e687b9f@[128.89.89.75]>
References: <013f01c3f0fa$f94d5170$[e-mail]> <p06020401bc514e687b9f@[128.89.89.75]>
X-Mailer: Open WebMail 1.81 20021127
X-OriginatingIP: 198.26.119.86 (chokhani)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

I agree.

On Thu, 12 Feb 2004 10:40:15 -0500, Stephen Kent wrote
> Santosh,
> 
> I agree with all of your observations in this context, except for 
> the use of the term "trust." Other than having to trust the bridge 
> CA to properly issue certs to the other CAs, use of the name 
> constraints extension is explicitly a way to not trust other CAs.  
> Rather, it is a way to recognize that a specific CA is authoritative 
> for a piece of a name space.
> 
> Steve






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CG2QnA041846; Thu, 12 Feb 2004 08:02:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CG2QTm041845; Thu, 12 Feb 2004 08:02:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CG2P2m041830 for <[e-mail]>; Thu, 12 Feb 2004 08:02:25 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1CG2bMB012012; Thu, 12 Feb 2004 11:02:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020401bc514e687b9f@[128.89.89.75]>
In-Reply-To: <013f01c3f0fa$f94d5170$[e-mail]>
References: <013f01c3f0fa$f94d5170$[e-mail]>
Date: Thu, 12 Feb 2004 10:40:15 -0500
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

I agree with all of your observations in this context, except for the 
use of the term "trust." Other than having to trust the bridge CA to 
properly issue certs to the other CAs, use of the name constraints 
extension is explicitly a way to not trust other CAs.  Rather, it is 
a way to recognize that a specific CA is authoritative for a piece of 
a name space.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CFiQo4040394; Thu, 12 Feb 2004 07:44:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CFiQN5040393; Thu, 12 Feb 2004 07:44:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CFiOLb040382 for <[e-mail]>; Thu, 12 Feb 2004 07:44:25 -0800 (PST) (envelope-from [e-mail])
Received: Message by Barricade atsgw.cyber.ee  with ESMTP id i1CFidad026703; Thu, 12 Feb 2004 17:44:40 +0200
Message-ID: <[e-mail]>
Date: Thu, 12 Feb 2004 17:44:38 +0200
From: Margus Freudenthal <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: Policy User Interfaces
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-info: Headers changed by Barricade
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:
> 
> > 1. add the "O=Foo Inc, OU=Kryptonium CA" root certificate among the
> > already installed ones.
> 
> > Not difference at all.
> 
> You missed out ...
> 
> 0. Spend a zillion groats deploying the Kryponium CA
> 
Even when using policies, you still have to create business process for
registering users and verifying that they really are worth the
kryptonium-level credit limit.

Adding an extra signing key for them should be minor problem, especially
assuming that you already have the necessary infrastructure (all the
minor level CA-s).


-- 
Margus



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CFOIXH038364; Thu, 12 Feb 2004 07:24:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CFOIBf038362; Thu, 12 Feb 2004 07:24:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CFOFo9038326 for <[e-mail]>; Thu, 12 Feb 2004 07:24:17 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 12 Feb 2004 16:24:09 +0100
Date: Thu, 12 Feb 2004 16:24:08 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Thu, 12 Feb 2004 14:20:48 +0000, [e-mail] said:

chris.gilbert> You missed out ...
chris.gilbert> 
chris.gilbert> 0. Spend a zillion groats deploying the Kryponium CA
chris.gilbert> 
chris.gilbert> :-)

True, but you had already said that.  I talked purely from an non-CA
administrative point of view :-).

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CFNIij038232; Thu, 12 Feb 2004 07:23:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CFNIDh038231; Thu, 12 Feb 2004 07:23:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CFNFoZ038225 for <[e-mail]>; Thu, 12 Feb 2004 07:23:15 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 12 Feb 2004 16:22:51 +0100
Date: Thu, 12 Feb 2004 16:22:50 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Thu, 12 Feb 2004 08:35:30 -0500, "Al Arsenault" <[e-mail]> said:

aarsenau> > So the question is, Al, what exactly are you asking for?
aarsenau> > That certificatePolicies should be possible to ignore even
aarsenau> > if your software has implemented support for it?  Some
aarsenau> > kind of "Extra Non-Critical" bit?  Sounds like a kludge
aarsenau> > big time to me.
aarsenau> 
aarsenau> Well, "world peace" and "the winning lottery ticket" are
aarsenau> always nice things to ask for.  :-)

:-) Thanks for the good laugh, Al.

Seriously, I understand better what you asked for now.

A small detail:

aarsenau> (Although I didn't explicitly ask this question, there
aarsenau> probably is a "middle option", where the definition of
aarsenau> certificatePolicies is changed to just allow one instance of
aarsenau> PolicyInformation - i.e., mandate "policy = CA". That might
aarsenau> save some code writing.)

I'm not sure how that would change things, or maybe I've just gravely
misunderstood how this is supposed to work?  The way I understand it,
the policy OID for a specific certificate is placed in the certificate
issued by the CA, not the CA certificate, so basically, you could have
the following:

+----+          +----------+
| CA |--------->| EE1      |
+----+          | Policy A |
  |             +----------+
  |
  |             +----------+
  +------------>| EE2      |
                | Policy B |
                +----------+

Those would be two EE certificates, issued with different policies and
still satisfying there only being on policy in certificatePolicies
(which then should be renamed to certificatePolicy :-)).

According to the path verification algorithm presented in RFC 3280, if
there are policies in a root certificate, they aren't even glanced at,
so that would imply there's no need to place policy certificates in
root certificates.  This is the part where I'm not 100% sure, though.
If I'm right, there's no technical way to limit a CA to only one
policy.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CFFF06037814; Thu, 12 Feb 2004 07:15:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CFFFH5037813; Thu, 12 Feb 2004 07:15:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1CFFEM4037806 for <[e-mail]>; Thu, 12 Feb 2004 07:15:14 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 17545 invoked by uid 0); 12 Feb 2004 15:15:28 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.159.184) by woodstock.binhost.com with SMTP; 12 Feb 2004 15:15:28 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 12 Feb 2004 10:07:26 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: clarification of CRL processing in RFC3280
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:31 PM 2/11/2004 -0800, Julien Pierre wrote:
>In section 6.3.3, (b) , RFC3280 states
>
>         (1)  If the DP includes cRLIssuer, then verify that the issuer
>         field in the complete CRL matches cRLIssuer in the DP and that
>         the complete CRL contains an issuing distribution point
>         extension with the indrectCRL boolean asserted.  Otherwise,
>         verify that the CRL issuer matches the certificate issuer.
>
>I am interested in a clarification of the "otherwise" case. What test is 
>specifically intended to match the CRL issuer to the certificate issuer ?

If Certificate.extensions.DistributionPoint.cRLIssuer is not present, then
    Certificate.issuer MUST match CertificateList.issuer

>(a). matching certificate
>(b). matching subject
>(c). some other entity matching test, and if so, which one ?
>
>It seems to me that (a) can't be the correct test, since even if DP/IDPs 
>are not used, both the certificate being verified and the CRL can still 
>contain AuthorityKeyID extensions, therefore making the CRL issuer 
>certificate distinct from the certificate's issuer certificate.

The same certificate is not required.  If this were required, then the CA 
would have a very difficult time rolling its signing key.  We need to allow 
the certificate to be signed by the 'old' key and the CRL to be signed by 
the 'new' key.

>(b) seems like a good test to require. This is what NSS does today. But I 
>can't help but think that it is not sufficient.
>If only the issuer subject matches, then technically the CRL issuer 
>certificate and certificate issuer certificate could in fact be otherwise 
>totally different, even chaining to different roots. This would be similar 
>to the case of indirect CRLs, except without the proper extensions. Would 
>that be acceptable under RFC3280 ? Is there something else I'm missing, 
>perhaps name constraints, that would invalidate this case ? It seems to 
>invite some attacks, which I will describe once I know the answer to my 
>inquiry.

Generally, they will be the same certificate.  When two different 
certificates are used, it should be die to the CA signing key being rolled 
over.  To this end, there has been discussion of also requiring the two 
certificates to terminate at the same trust anchor.  What if it is the 
trust anchor that is rolling over its signing key?

Basically, it comes down to an old problem.  One needs to make sure that 
there cannot be two CAs operating with the same distinguished name.

>(c) Hopefully this is the correct answer. Which is the more comprehensive 
>matching test to be used in this case ?

Answered above.

Russ 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CEodRt035648; Thu, 12 Feb 2004 06:50:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CEodhW035647; Thu, 12 Feb 2004 06:50:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vahqex3.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CEoct9035638 for <[e-mail]>; Thu, 12 Feb 2004 06:50:38 -0800 (PST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----_=_NextPart_001_01C3F177.9F585734"; type="multipart/alternative"
Subject: RE: Policy User Interfaces
Date: Thu, 12 Feb 2004 09:50:57 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Policy User Interfaces
Thread-Index: AcPxd1FZ7JrgGfjoQPuIqAh8aJBVcAAAB+9w
From: "Oshman, Dave" <[e-mail]>
To: <[e-mail]>, "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3F177.9F585734
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C3F177.9F585734"


------_=_NextPart_002_01C3F177.9F585734
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That is an important point, Chris!
=20
>From my experiences in the financial sector, banks don't want to have a
lot of CAs as there is a cost to install and run and audit each
individual CA. With Identrus, the choice made was to have a single CA
that issues certificates with different policies--in some cases multiple
policies. Having a CA for each policy would be totally cost-prohibitive
in a regulated industry like banking.=20

Identrus (as of 14 months ago when I last worked with them) relies
heavily on certificate policies as envisioned by 3280. Legally, they
rely on the fact that since certificate policies is marked critical,
"outside" applications should not accept Identrus certificates since
they shouldn't have access to the documentation required to make the
decision whether or not to rely on a certificate. Changing an aspect of
3280 at this point in time could wreak havoc here.

Dave Oshman
DigitalNet Government Solutions
301/939-2736
410/880-6095
800/999-3732
301/939-2901 (fax)

  _____ =20

From: [e-mail] [mailto:[e-mail]]=20
Sent: Thursday, February 12, 2004 9:21 AM
To: Richard Levitte - VMS Whacker
Cc: [e-mail]; [e-mail]
Subject: Re: Policy User Interfaces



 Richard Levitte - VMS Whacker <[e-mail]>

> Not much of a difference, really. Now, suppose Foo Inc adds a
> Kryptonium policy with a $10M credit limit. Of course, our example
> business wants to include people with that kind of credit policy among
> their customers (they would hardly say "you have too high a limit, so
> we can't trust you"). To do that, they would have to perform one of
> the following actions:

> 1. add the "O=3DFoo Inc, OU=3DKryptonium CA" root certificate among =
the
> already installed ones.

> Not difference at all.

You missed out ...

0. Spend a zillion groats deploying the Kryponium CA

:-)
**********************************************************************
This email and any attachments are confidential and intended for the
addressee only. If you are not the named recipient, you must not use,
disclose, reproduce, copy or distribute the contents of this
communication. If you have received this in error, please contact the
sender and then delete this email from your system.
**********************************************************************=20

------_=_NextPart_002_01C3F177.9F585734
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D742394914-12022004><FONT =
size=3D2>That is an=20
important point, Chris!</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D742394914-12022004><FONT=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D742394914-12022004><FONT =
size=3D2>From my=20
experiences in the financial sector, banks don't want to have a lot of =
CAs as=20
there is a cost to install and run and audit each individual CA. With =
Identrus,=20
the choice made was to have a single CA that issues certificates with =
different=20
policies--in some cases multiple policies. Having a CA for each policy =
would be=20
totally cost-prohibitive in a regulated industry like banking. </DIV>
<DIV dir=3Dltr align=3Dleft>
<P>Identrus (as of 14 months ago when I last worked with them) relies =
heavily on=20
certificate policies as envisioned by 3280. Legally, they rely on the =
fact that=20
since certificate policies is marked critical, "outside" applications =
should not=20
accept Identrus certificates since they shouldn't have access to the=20
documentation required to make the decision whether or not to rely on a=20
certificate. Changing an aspect of 3280 at this point in time could =
wreak havoc=20
here.</P></FONT></SPAN></DIV>
<DIV align=3Dleft><EM><FONT color=3D#008000>Dave =
Oshman</FONT></EM></DIV>
<DIV align=3Dleft><FONT face=3DTahoma color=3D#008000>DigitalNet =
Government=20
Solutions</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma =
color=3D#008000>301/939-2736</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma =
color=3D#008000>410/880-6095</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma =
color=3D#008000>800/999-3732</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma color=3D#008000>301/939-2901=20
(fax)</FONT></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <BR><B>Sent:</B> Thursday, February =
12,=20
2004 9:21 AM<BR><B>To:</B> Richard Levitte - VMS Whacker<BR><B>Cc:</B>=20
[e-mail]; [e-mail]<BR><B>Subject:</B> Re: =
Policy User=20
Interfaces<BR></FONT><BR></DIV>
<DIV></DIV><BR><IMG height=3D16=20
alt=3D"Inactive hide details for Richard Levitte - VMS Whacker =
<[e-mail]>"=20
src=3D"cid:742394914@12022004-2AA4" width=3D16>Richard Levitte - VMS =
Whacker=20
&lt;[e-mail]&gt;<BR><BR><FONT face=3D"Courier New">&gt; Not much of =
a=20
difference, really. Now, suppose Foo Inc adds a<BR>&gt; Kryptonium =
policy with a=20
$10M credit limit. Of course, our example<BR>&gt; business wants to =
include=20
people with that kind of credit policy among<BR>&gt; their customers =
(they would=20
hardly say "you have too high a limit, so<BR>&gt; we can't trust you"). =
To do=20
that, they would have to perform one of<BR>&gt; the following=20
actions:<BR></FONT><BR><FONT face=3D"Courier New">&gt; 1. add the =
"O=3DFoo Inc,=20
OU=3DKryptonium CA" root certificate among the<BR>&gt; already installed =

ones.</FONT><BR><BR><FONT face=3D"Courier New">&gt; Not difference at=20
all.</FONT><BR><BR><FONT face=3D"Courier New">You missed out=20
...</FONT><BR><BR><FONT face=3D"Courier New">0. Spend a zillion groats =
deploying=20
the Kryponium CA</FONT><BR><BR><FONT face=3D"Courier New">:-)</FONT>=20
********************************************************************** =
This=20
email and any attachments are confidential and intended for the =
addressee only.=20
If you are not the named recipient, you must not use, disclose, =
reproduce, copy=20
or distribute the contents of this communication. If you have received =
this in=20
error, please contact the sender and then delete this email from your =
system.=20
**********************************************************************=20
</BODY></HTML>

------_=_NextPart_002_01C3F177.9F585734--

------_=_NextPart_001_01C3F177.9F585734
Content-Type: image/gif;
	name="graycol.gif"
Content-Transfer-Encoding: base64
Content-ID: <742394914@12022004-2AA4>
Content-Description: graycol.gif
Content-Location: graycol.gif

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

------_=_NextPart_001_01C3F177.9F585734--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CEkNo7035401; Thu, 12 Feb 2004 06:46:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CEkNUT035400; Thu, 12 Feb 2004 06:46:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CEkKLx035390 for <[e-mail]>; Thu, 12 Feb 2004 06:46:22 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP for <[e-mail]>; Thu, 12 Feb 2004 15:46:20 +0100
Date: Thu, 12 Feb 2004 15:46:19 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Policy OID => CP mapping (was: Policy User Interfaces)
From: Richard Levitte - VMS Whacker <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Guys,

as part of this whole certificate policy discussion, there's one point
that I'd like to take up where I haven't really seen a good solution:
distribution of CPs.  Yes, one can have a CPS URI and that can link
further from there to the CP, or (*cough*) one might use a userNotice
to point at the CP.  Still, that's a fairly crude way to handle it,
and some just don't.  It would be a good thing if there was some
formalised way to find a CP given a policy OID.

I do not care what kind of technology would be used, if one would
imagine finding CP pointers in LDAP, or via some contorted DNS RRs, or
some new, entirely separate protocol (and no, I don't think
Alvestrands object database, however nice it is to browse, is the
solution :-)).

Of course, some organizations may choose not to publish their CPs.
Their choice, and maybe their loss, I couldn't care less.  What I care
about is that there seems to be no technical way at all to find the CP
connected to a policy OID.

As usual, if I'm misinformed, I'd love to stand corrected.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CER9YQ034154; Thu, 12 Feb 2004 06:27:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CER91M034153; Thu, 12 Feb 2004 06:27:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CER83n034144 for <[e-mail]>; Thu, 12 Feb 2004 06:27:08 -0800 (PST) (envelope-from [e-mail])
Received: from ng171tdnot45.royalmail.com (unknown [144.87.146.19]) by mail3.consignia.com (Postfix) with ESMTP id 4F5481C1942; Thu, 12 Feb 2004 14:26:36 +0000 (GMT)
Subject: Re: Policy User Interfaces
To: Richard Levitte - VMS Whacker <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 12 Feb 2004 14:20:48 +0000
X-MIMETrack: Serialize by Router on m22ng32/H/MTANET(Release 6.5|September 26, 2003) at 12/02/2004 14:26:36
MIME-Version: 1.0
Content-type: multipart/related;  Boundary="0__=8FBBE4ABDFDDF0D58f9e8a93df938690918c8FBBE4ABDFDDF0D5"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=8FBBE4ABDFDDF0D58f9e8a93df938690918c8FBBE4ABDFDDF0D5
Content-type: multipart/alternative; 
	Boundary="1__=8FBBE4ABDFDDF0D58f9e8a93df938690918c8FBBE4ABDFDDF0D5"

--1__=8FBBE4ABDFDDF0D58f9e8a93df938690918c8FBBE4ABDFDDF0D5
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable




> Not much of a difference, really.  Now, suppose Foo Inc adds a
> Kryptonium policy with a $10M credit limit.  Of course, our example
> business wants to include people with that kind of credit policy amon=
g
> their customers (they would hardly say "you have too high a limit, so=

> we can't trust you").  To do that, they would have to perform one of
> the following actions:

 > 1. add the "O=3DFoo Inc, OU=3DKryptonium CA" root certificate among =
the
    > already installed ones.

> Not difference at all.

You missed out ...

0. Spend a zillion groats deploying the Kryponium CA

:-)


     ******************************************************************=
****
     This email and any attachments are confidential and intended for t=
he
     addressee only. If you are not the named recipient, you must not u=
se,
     disclose, reproduce, copy or distribute the contents of this
     communication. If you have received this in error, please contact =
the
     sender and then delete this email from your system.
     ******************************************************************=
****

=

--1__=8FBBE4ABDFDDF0D58f9e8a93df938690918c8FBBE4ABDFDDF0D5
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body><br>
<img src=3D"cid:10__=[e-mail]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for Richard Levitte - V=
MS Whacker &lt;[e-mail]&gt;">Richard Levitte - VMS Whacker &lt;lev=
[e-mail]&gt;<br>
<br>
<font face=3D"Courier New">&gt; Not much of a difference, really.  Now,=
 suppose Foo Inc adds a<br>
&gt; Kryptonium policy with a $10M credit limit.  Of course, our exampl=
e<br>
&gt; business wants to include people with that kind of credit policy a=
mong<br>
&gt; their customers (they would hardly say &quot;you have too high a l=
imit, so<br>
&gt; we can't trust you&quot;).  To do that, they would have to perform=
 one of<br>
&gt; the following actions:<br>
</font><br>
<font face=3D"Courier New">&gt; 1. add the &quot;O=3DFoo Inc, OU=3DKryp=
tonium CA&quot; root certificate among the<br>
&gt; already installed ones.</font><br>
<br>
<font face=3D"Courier New">&gt; Not difference at all.</font><br>
<br>
<font face=3D"Courier New">You missed out ...</font><br>
<br>
<font face=3D"Courier New">0. Spend a zillion groats deploying the Kryp=
onium CA</font><br>
<br>
<font face=3D"Courier New">:-)</font>


**********************************************************************
This email and any attachments are confidential and intended for the ad=
dressee only. If you are not the named recipient, you must not use, dis=
close, reproduce, copy or distribute the contents of this communication=
. If you have received this in error, please contact the sender and the=
n delete this email from your system.
**********************************************************************


</body></html>=


--1__=8FBBE4ABDFDDF0D58f9e8a93df938690918c8FBBE4ABDFDDF0D5--


--0__=8FBBE4ABDFDDF0D58f9e8a93df938690918c8FBBE4ABDFDDF0D5
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <10__=[e-mail]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4ABDFDDF0D58f9e8a93df938690918c8FBBE4ABDFDDF0D5--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CEF4xk033224; Thu, 12 Feb 2004 06:15:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CEF4TO033223; Thu, 12 Feb 2004 06:15:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CEF2Rm033217 for <[e-mail]>; Thu, 12 Feb 2004 06:15:02 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 12 Feb 2004 15:15:14 +0100
Date: Thu, 12 Feb 2004 15:15:14 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <001c01c3f166$ba19b130$0500a8c0@arport>
References: <017201c3f14b$16b6b620$0500a8c0@arport> <[e-mail]> <001c01c3f166$ba19b130$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <001c01c3f166$ba19b130$0500a8c0@arport> on Thu, 12 Feb 2004 13:49:39 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Here you "policy-OID-zealots" lose me completely.

Hmm, that's the first time I've been called a zealot.  Is that good or
bad?  :-)

anders.rundgren> Assume that you are in the situation where you have
anders.rundgren> to decide whether you are going to accept a new trust
anders.rundgren> anchor or not.  Then you [maybe] read the CP and make
anders.rundgren> the decision to "trust" this and installs the trusts
anders.rundgren> anchor.  If the trust anchor represents a single
anders.rundgren> policy CA, you don't have to bother about anything
anders.rundgren> more.

Hmm.  An example: say there's a business that deals with fairly
expensive stuff, and will therefore only deal with people that can
show they have a minimum credit limit of $100k.  They can verify
certain certificates that correspond to the Silver ($10k limit),
Gold ($100k limit) and Platinum ($1M limit) policies.  To have their
software work with this, they need to configure it with information on
what kind of data is acceptable.  As far as I can see, here's how they
would handle it:

 1. the policy=CA scenario: install the "O=Foo Inc, OU=Platinum CA"
    and "O=Foo Inc, OU=Gold CA" root certificates.
 2. the multi-policy CA scenario: install the "O=Foo Inc, OU=CA" root
    certificate and the policy OIDs corresponding to Gold and
    Platinum.

Not much of a difference, really.  Now, suppose Foo Inc adds a
Kryptonium policy with a $10M credit limit.  Of course, our example
business wants to include people with that kind of credit policy among
their customers (they would hardly say "you have too high a limit, so
we can't trust you").  To do that, they would have to perform one of
the following actions:

 1. add the "O=Foo Inc, OU=Kryptonium CA" root certificate among the
    already installed ones.
 2. add the Kryptonium policy OID among the already installed policy
    OIDs.

Not difference at all.  After all, to do this at all, they have to be
informed, one way or another, that there's a new policy and what
pieces of data come with it.  And either way, don't you think that our
example business would like to know the conditions applied to the new
policy, i.e. read some kind of policy document?  How are things like
this handled with credit cards today?  Am I about to be desillusioned?

I really don't understand how the scenarios above would be performed
without some kind of human action and awareness.  I doubt "magic" is
an appropriate response...

anders.rundgren> >And if you're thinking of just having an increasing
anders.rundgren> >list of roots in your software, just think how
anders.rundgren> >hellish it will be for *every* user or administrator
anders.rundgren> >everytime a new CA pops up just because some company
anders.rundgren> >sets up a new policy.
anders.rundgren> 
anders.rundgren> This is based on the rather speculative idea that CAs
anders.rundgren> add policies at their wim.  But if policies are NOT
anders.rundgren> standardized users still get the very same problem:
anders.rundgren> a blocked communication channel.

Uhmm, I wasn't really implying "at their wim", but you can't really
deny that policy changes and additions DO happen, and when that
happens, there is some new information that you will need to deal with
if you want to bother with the changes or additions at all.

anders.rundgren> This is what makes people REALLY upset and RIGHTFULLY
anders.rundgren> wanting that userid/password stuff back, as it had no
anders.rundgren> legal issues, no policy "crap", and you can just
anders.rundgren> phone it to the other guy.

Are you talking about people like users or people like business
administrators?  I can fully understand that your regular J. Random
User doesn't give a crap about policies more than possibly the pamflet
he gets to read when he got his brand new credit card (most people do
not read that either).  I don't expect J. Random User to check the
policies that come with the certificate served by https://foo.com/.
However, if Random Bank Inc does business with all kinds of customers
and use the customers' client certificate for authentication and other
checks, I would be *really* surprised if they wouldn't want to know
what credit limits come with those.  Things like credit limits would,
as far as I can see, come as part of the certificate policy in those
client certificates.  I'm quite sure that bank *does* care about such
stuff.

Of course, the bank example requires either that they have done a bit
of cross certification with credit companies or other banks, or that
their customers all have certificates issued by said bank.

But of course, that bank can as well use userid/password and have the
rest in a database.  It's all part of what you believe in and if you
want to be able to use information coming from other sources or not.

anders.rundgren> I believe this situation will limit the applicability
anders.rundgren> of multi-policy CAs considerably.

I think that your scenario may limit the applicability of X.509/PKIX
at all, just as much as multi-policy CAs.

anders.rundgren> Agreeably, I work with open scenarios where
anders.rundgren> competence is zero or below.  It is challenging in
anders.rundgren> its own mysterious ways...

Now, *that* is something I agree with, and I do believe that those of
us that feel they have enough competence have a more or less implied
role as educators.  Of course, one has to be willing to educate in the
first place...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CEDKQd033099; Thu, 12 Feb 2004 06:13:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CEDKo3033098; Thu, 12 Feb 2004 06:13:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CEDJef033088 for <[e-mail]>; Thu, 12 Feb 2004 06:13:19 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i1CEDajK003990 for <[e-mail]>; Thu, 12 Feb 2004 09:13:36 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: clarification of CRL processing in RFC3280
Date: Thu, 12 Feb 2004 09:13:28 -0500
MIME-Version: 1.0
Message-ID: <005501c3f172$67d58c80$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0051_01C3F148.7A067A10"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

Julien:

Let us say that you are checking the revocation status of certificate "X
and you have obtained CRL A (using CDP or other means).  The check is
saying that verify Issue of X == Issuer of A.

This check is helpful when CA has rekeyed and the certificate and CRL are
not signed using the same or if the CA uses different keys to sign
certificates and CRLs.

Few months ago, I pointed out that X.509 and 3280 need to be enhanced
since this check is not sufficient.  Only Denis Pinkas responded to it and
I interpreted his statement as agreement to my proposal.  The checks are
to ensure that the both certification paths (for the certificate in
question and for CRL being checked for it) being with the same trust
anchor issuer/subject name and the names in the two paths match ignoring
self-issued certificates.  The actual text is more precise and appears in
the latest Path Development I-D (on Informational RFC track).

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Julien Pierre
Sent: Thursday, February 12, 2004 2:32 AM
To: [e-mail]
Subject: clarification of CRL processing in RFC3280


Hi,

In section 6.3.3, (b) , RFC3280 states

         (1)  If the DP includes cRLIssuer, then verify that the issuer
         field in the complete CRL matches cRLIssuer in the DP and that
         the complete CRL contains an issuing distribution point
         extension with the indrectCRL boolean asserted.  Otherwise,
         verify that the CRL issuer matches the certificate issuer.

I am interested in a clarification of the "otherwise" case. What test is
specifically intended to match the CRL issuer to the certificate issuer ?

(a). matching certificate
(b). matching subject
(c). some other entity matching test, and if so, which one ?

It seems to me that (a) can't be the correct test, since even if DP/IDPs
are not used, both the certificate being verified and the CRL can still
contain AuthorityKeyID extensions, therefore making the CRL issuer
certificate distinct from the certificate's issuer certificate.

(b) seems like a good test to require. This is what NSS does today. But
I can't help but think that it is not sufficient.
If only the issuer subject matches, then technically the CRL issuer
certificate and certificate issuer certificate could in fact be
otherwise totally different, even chaining to different roots. This
would be similar to the case of indirect CRLs, except without the proper
extensions. Would that be acceptable under RFC3280 ? Is there something
else I'm missing, perhaps name constraints, that would invalidate this
case ? It seems to invite some attacks, which I will describe once I
know the answer to my inquiry.

(c) Hopefully this is the correct answer. Which is the more
comprehensive matching test to be used in this case ?


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

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

------=_NextPart_000_0051_01C3F148.7A067A10--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CDZWbg029903; Thu, 12 Feb 2004 05:35:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CDZWX6029901; Thu, 12 Feb 2004 05:35:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CDZVJ5029868 for <[e-mail]>; Thu, 12 Feb 2004 05:35:31 -0800 (PST) (envelope-from [e-mail])
Received: from arsenaultd2 (col-dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i1CDZaM8003557; Thu, 12 Feb 2004 08:35:39 -0500 (EST)
From: "Al Arsenault" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Policy User Interfaces
Date: Thu, 12 Feb 2004 08:35:30 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Richard Levitte - VMS
> Whacker
> Sent: Wednesday, February 11, 2004 4:55 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Policy User Interfaces
>
>
> So the question is, Al, what exactly are you asking for?  That
> certificatePolicies should be possible to ignore even if your software
> has implemented support for it?  Some kind of "Extra Non-Critical"
> bit?  Sounds like a kludge big time to me.
>


Well, "world peace" and "the winning lottery ticket" are always nice things
to ask for.  :-)

Seriously, my question was posed based on my understanding of what it means
when an RFC like 3280 requires support for a feature.  That is, the feature
is required to be present in the code; it is not necessary that it be used
in any given instantiation (unless that is specified).

So, when RFC 3280 requires that conforming CAs MUST support (among others)
cert policies, a conforming CA must contain code which can create a
certificate with a valid Cert Policies extension. It does not mean that a
particular user of that CA product must create certificates with that
extension present; OR that certificates with the cert policies extension
present must mark it critical or non-critical.

(Note that since certificatePolicies is a SEQUENCE SIZE (1..MAX) OF
PolicyInformation, this necessarily means that the code can support >1
policy per CA.  It doesn't mean any given customer ever has to use that in
practice, just that the code has to be able to support it if somebody wants
to build a system that way.)

Similarly for relying party software.  Right now, a conforming application
must recognize (among others) the certificate policies extension.  That does
not mean that all certificates the application will process have the
extension in them; just that if there is such a certificate with the
extension marked critical, the application can't reject the certificate for
lack of recognizing the extension.

So, if support for the cert policies extension is made optional, this means
it would be okay:

	- to build a CA implementation that is not capable in any circumstance of
populating the certificate policies extension, and still call that CA
"conforming".

	- to build an RP application that does not recognize the certificate
policies extension, and still call that application "conforming".  Thus, if
such an RP application encountered a certificate with a critical
certificatePolicies extension, that application would fail to validate the
certificate, and this would be "conforming" with PKIX.

The implication is that, under the current requirement, the developer has to
write some (a lot of?) code to process those situations where somebody does
put in the full cert policies stuff, with all the chrome, tail fins, etc.
about which Peter speaks.  (And it has to be documented, tested, etc.) If we
change, the developer doesn't have to write that code.

That was the question I asked - was there any support for changing 3280 to
eliminate the need for the developers to write this code?

(Although I didn't explicitly ask this question, there probably is a "middle
option", where the definition of certificatePolicies is changed to just
allow one instance of PolicyInformation - i.e., mandate "policy = CA". That
might save some code writing.)

We haven't had a straw poll, and I think doing so would be a waste of time
and bits, but so far only Peter G., Michael Stroder, and Anders R. (sort of)
have supported this change.  There have been a number of resounding "NO"
opinions expressed, from Steve Hanna, Rich Guida, Santosh, and yourself,
Richard.

My own opinion is also to keep 3280 the way it is.  There's nothing in 3280
that requires any PKI user to implement cert policies, or that they support
>1 cert policy per CA.  Conforming products should have this code in them,
though.  We can argue all day (and it wouldn't be the first time) on how
user-friendly or not; or how elegant or not; the implementation of the code
and the user interface to these features is.  But that's not relevant to
whether or not it should be a 3280 requirement.

I base my opinion on the following:

	- there are some customers/PKI users who explicitly want and are using
these features, for sound security and efficiency reasons (the fact that
some people on this list don't interact with those PKI users isn't relevant;
they exist and proclaim to want the features)

	- a number of significant producers of PKI products, both CA and
application, have said that they already support this requirement.  Largely,
we've just discussed how elegant their user/management interfaces are, not
whether they lied when they said they supported this requirement

Now, as always, PKI has a long way to go before it can "take over the world"
as was once promised.  I think most of us know that PKI was overhyped and
overpriced, as well as misunderstood and probably targetted at the wrong
problem way too often.  But I don't think that changing 3280 to make support
for cert policies optional will help that; nor do I think changing 3280 to
modify certpolicies so that only one policy is permitted will help.

					Al Arsenault




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CCtg0b026953; Thu, 12 Feb 2004 04:55:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CCtgAl026952; Thu, 12 Feb 2004 04:55:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-2-sn1.fre.skanova.net (av7-2-sn1.fre.skanova.net [81.228.11.114]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CCte2n026942 for <[e-mail]>; Thu, 12 Feb 2004 04:55:41 -0800 (PST) (envelope-from [e-mail])
Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id 7DF0437EA3; Thu, 12 Feb 2004 13:55:53 +0100 (CET)
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id 5BE2937E78; Thu, 12 Feb 2004 13:55:53 +0100 (CET)
Received: from arport (t8o913p61.telia.com [213.64.26.181]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id i1CCtkIC002244; Thu, 12 Feb 2004 13:55:46 +0100 (CET)
Message-ID: <001c01c3f166$ba19b130$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>            <017201c3f14b$16b6b620$0500a8c0@arport> <[e-mail]>
Subject: Re: Policy User Interfaces
Date: Thu, 12 Feb 2004 13:49:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>I agree with "Dream on", and I've got a question for you: what makes
>you think any policy OID would *replace* CP documents?  Do you imagine
>that there would be some kind of magic policy OID that is implicitely
>understood as far as responsabilities and liabilities and so on go?  I
>can't recall anyone talking about any replacement here, and I'd
>suspect that noone would.  I dunno about you, but I'm not ready to
>take any policy OID on a "carte blanche" basis.  I wanna read what it
>means.

Here you "policy-OID-zealots" lose me completely.  Assume that you
are in the situation where you have to decide whether you are going
to accept a new trust anchor or not.  Then you [maybe] read the CP
and make the decision to "trust" this and installs the trusts anchor.  If
the trust anchor represents a single policy CA, you don't have to bother
about anything more.

>And if you're thinking of just having an increasing list of roots
>in your software, just think how hellish it will be for *every*
>user or administrator everytime a new CA pops up just because
>some company sets up a new policy.

This is based on the rather speculative idea that CAs add policies
at their wim.  But if policies are NOT standardized users still get
the  very same problem: a blocked communication channel. 
This is what makes people REALLY upset and RIGHTFULLY
wanting that userid/password stuff back, as it had no legal issues,
no policy "crap", and you can just phone it to the other guy.

I believe this situation will limit the applicability of multi-policy
CAs considerably.

Agreeably, I work with open scenarios where competence is
zero or below.  It is challenging in its own mysterious ways...

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CC8RZ9023548; Thu, 12 Feb 2004 04:08:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1CC8RJ2023547; Thu, 12 Feb 2004 04:08:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CC8L10023541 for <[e-mail]>; Thu, 12 Feb 2004 04:08:22 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 12 Feb 2004 13:08:24 +0100
Date: Thu, 12 Feb 2004 13:08:24 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <017201c3f14b$16b6b620$0500a8c0@arport>
References: <[e-mail]> <017201c3f14b$16b6b620$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <017201c3f14b$16b6b620$0500a8c0@arport> on Thu, 12 Feb 2004 10:32:08 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> >I do not support, however, the addition of detail
anders.rundgren> >that is merely a flavour of something that already
anders.rundgren> >exists within the standards, even if it is a more
anders.rundgren> >simplistic and easy-to-use representation.
anders.rundgren> 
anders.rundgren> So you really mean that there WILL be a LIMITED SET
anders.rundgren> of UNIVERSALLY globally accepted policy OIDs that
anders.rundgren> effectively replaces CP documents?  And COTS
anders.rundgren> application will be pre-programmed accordingly?
anders.rundgren> 
anders.rundgren> If this interpretation is correct I can only say:
anders.rundgren> Dream on.

I agree with "Dream on", and I've got a question for you: what makes
you think any policy OID would *replace* CP documents?  Do you imagine
that there would be some kind of magic policy OID that is implicitely
understood as far as responsabilities and liabilities and so on go?  I
can't recall anyone talking about any replacement here, and I'd
suspect that noone would.  I dunno about you, but I'm not ready to
take any policy OID on a "carte blanche" basis.  I wanna read what it
means.  To compare with a real-world example, how many do you think
would want to handle a credit card without that sheet of legal terms?
As you said: dream on...

anders.rundgren> My "dreams" are based on the fact vendors SHOULD
anders.rundgren> NEVER *have* to agree on things they consider "their
anders.rundgren> own business".  Policy is definitely (unless the UN
anders.rundgren> is involved), community or business defined.

Yes?  To get back to certificates, what would make a business have to
agree on someone else's policy (except in a cross-certification case,
but that is rather about policy mappings than agreeing to use someone
else's policies...)?

anders.rundgren> And there are MANY communities and businesses!

Yes?  I don't exactly see that as a problem per se.  I *do* see the
policy=CA thought as a problem, though, as that only increases the
pletora (sp?) of choices and definitely complicates communications
between the communities and businesses...  or for the users with their
communities or businesses, for that matter...

anders.rundgren> This is why the policy system [on a wider scale] is
anders.rundgren> likely to end-up as the global X.500 directory, as a
anders.rundgren> "vision".
anders.rundgren> 
anders.rundgren> This is also why I insist recommending single-policy
anders.rundgren> CAs as they are independent of "dreams" and
anders.rundgren> "visions", they just work.  Albeit at a premium for
anders.rundgren> the owner.

I'd say that they kinda work, right now, in form of closed communities
and businesses (come on, since when can you, as a VeriSign certificate
recipient, verify a Thawte (uhmm, they're still using their own roots,
right?) certificate, having only the VeriSign roots as trust anchor?
Until you can, VeriSign is a close community, as is Thawte, as is...).
When you start to have communication across CA borders (and I'm
thinking cross certification would be the tool of choice), having
fewer roots to cross-certify is a good thing.  And if you're thinking
of just having an increasing list of roots in your software, just
think how hellish it will be for *every* user or administrator
everytime a new CA pops up just because some company sets up a new
policy.

But then again, we don't have the kind of communication across CA
borders that I'm talking about (and according to pessimistic voices
never will, since we don't have it today) yet, so it's true, today it
"works"...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1C9vI49009773; Thu, 12 Feb 2004 01:57:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1C9vIql009772; Thu, 12 Feb 2004 01:57:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1C9vGPY009752 for <[e-mail]>; Thu, 12 Feb 2004 01:57:16 -0800 (PST) (envelope-from [e-mail])
Received: from ng171tdnot45.royalmail.com (unknown [144.87.146.19]) by mail3.consignia.com (Postfix) with ESMTP id 4F3BC1C0F0E; Thu, 12 Feb 2004 09:54:05 +0000 (GMT)
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 12 Feb 2004 09:51:45 +0000
X-MIMETrack: Serialize by Router on m22ng32/H/MTANET(Release 6.5|September 26, 2003) at 12/02/2004 09:54:05
MIME-Version: 1.0
Content-type: multipart/related;  Boundary="0__=8FBBE4ABDFA6F3DD8f9e8a93df938690918c8FBBE4ABDFA6F3DD"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=8FBBE4ABDFA6F3DD8f9e8a93df938690918c8FBBE4ABDFA6F3DD
Content-type: multipart/alternative; 
	Boundary="1__=8FBBE4ABDFA6F3DD8f9e8a93df938690918c8FBBE4ABDFA6F3DD"

--1__=8FBBE4ABDFA6F3DD8f9e8a93df938690918c8FBBE4ABDFA6F3DD
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable




> So you really mean that there WILL be a LIMITED SET of
> UNIVERSALLY globally accepted policy OIDs that effectively
> replaces CP documents?  And COTS application will be
> pre-programmed accordingly?

Absolutely not.

(( BTW, is there any difference between a universal CP and
   Policy Certificates ? It would appear to me that they
   are one and the same. ))

> And there are MANY communities and businesses!

Agreed, and consumers have the power of choice to buy into a
policy that meets thier needs or to pay a provider to create
a policy for them that meets thier needs. Either that or
they build thier own CA and create thier own policies.

Chris


**********************************************************************
This email and any attachments are confidential and intended for the
addressee only. If you are not the named recipient, you must not use,
disclose, reproduce, copy or distribute the contents of this communicat=
ion.
If you have received this in error, please contact the sender and then
delete this email from your system.
**********************************************************************

=

--1__=8FBBE4ABDFA6F3DD8f9e8a93df938690918c8FBBE4ABDFA6F3DD
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body><br>
<img src=3D"cid:10__=[e-mail]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for &quot;Anders Rundgr=
en&quot; &lt;[e-mail]&gt;">&quot;Anders Rundgren&quot;=
 &lt;[e-mail]&gt;<br>
<br>
<font face=3D"Courier New">&gt; So you really mean that there WILL be a=
 LIMITED SET of<br>
&gt; UNIVERSALLY globally accepted policy OIDs that effectively<br>
&gt; replaces CP documents?  And COTS application will be<br>
&gt; pre-programmed accordingly?</font><br>
<br>
<font face=3D"Courier New">Absolutely not.</font><br>
<br>
<font face=3D"Courier New">(( BTW, is there any difference between a un=
iversal CP and</font><br>
<font face=3D"Courier New">   Policy Certificates ? It would appear to =
me that they</font><br>
<font face=3D"Courier New">   are one and the same. ))<br>
</font><br>
<font face=3D"Courier New">&gt; And there are MANY communities and busi=
nesses!</font><br>
<br>
<font face=3D"Courier New">Agreed, and consumers have the power of choi=
ce to buy into a </font><br>
<font face=3D"Courier New">policy that meets thier needs or to pay a pr=
ovider to create</font><br>
<font face=3D"Courier New">a policy for them that meets thier needs. Ei=
ther that or</font><br>
<font face=3D"Courier New">they build thier own CA and create thier own=
 policies.<br>
</font>Chris


**********************************************************************
This email and any attachments are confidential and intended for the ad=
dressee only. If you are not the named recipient, you must not use, dis=
close, reproduce, copy or distribute the contents of this communication=
. If you have received this in error, please contact the sender and the=
n delete this email from your system.
**********************************************************************


</body></html>=


--1__=8FBBE4ABDFA6F3DD8f9e8a93df938690918c8FBBE4ABDFA6F3DD--


--0__=8FBBE4ABDFA6F3DD8f9e8a93df938690918c8FBBE4ABDFA6F3DD
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <10__=[e-mail]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4ABDFA6F3DD8f9e8a93df938690918c8FBBE4ABDFA6F3DD--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1C9bpKc002923; Thu, 12 Feb 2004 01:37:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1C9bpAO002922; Thu, 12 Feb 2004 01:37:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-2-sn1.fre.skanova.net (av7-2-sn1.fre.skanova.net [81.228.11.114]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1C9bo5f002884 for <[e-mail]>; Thu, 12 Feb 2004 01:37:51 -0800 (PST) (envelope-from [e-mail])
Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id E039137E70; Thu, 12 Feb 2004 10:38:02 +0100 (CET)
Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id D5C2B37E52 for <[e-mail]>; Thu, 12 Feb 2004 10:38:02 +0100 (CET)
Received: from arport (t12o913p71.telia.com [213.64.28.191]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 13C4F37E6D; Thu, 12 Feb 2004 10:38:01 +0100 (CET)
Message-ID: <017201c3f14b$16b6b620$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Thu, 12 Feb 2004 10:32:08 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I do not support, however, the addition of
>detail that is merely a flavour of something that already exists
>within the standards, even if it is a more simplistic and
>easy-to-use representation.

So you really mean that there WILL be a LIMITED SET of
UNIVERSALLY globally accepted policy OIDs that effectively
replaces CP documents?  And COTS application will be
pre-programmed accordingly?

If this interpretation is correct I can only say: Dream on.

My "dreams" are based on the fact vendors SHOULD NEVER
*have* to agree on things they consider "their own business".  Policy is
definitely (unless the UN is involved), community or business defined.

And there are MANY communities and businesses!

This is why the policy system [on a wider scale] is likely
to end-up as the global X.500 directory, as a "vision".

This is also why I insist recommending single-policy CAs
as they are independent of  "dreams" and "visions", they just
work.  Albeit at a premium for the owner.

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1C7S9Bp059171; Wed, 11 Feb 2004 23:28:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1C7S9KQ059169; Wed, 11 Feb 2004 23:28:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from scale01.mcom.com (h-64-236-139-249.aoltw.net [64.236.139.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1C7S8d6059133 for <[e-mail]>; Wed, 11 Feb 2004 23:28:08 -0800 (PST) (envelope-from [e-mail])
Received: from aol.net ([10.169.150.144]) by scale01.nscp.aoltw.net (Netscape Messaging Server 6.1 (built Oct  3 2002)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 11 Feb 2004 23:27:49 -0800 (PST)
Date: Wed, 11 Feb 2004 23:31:45 -0800
From: Julien Pierre <[e-mail]>
Subject: clarification of CRL processing in RFC3280
To: [e-mail]
Reply-to: [e-mail]
Message-id: <[e-mail]>
Organization: America On-Line, Inc
MIME-version: 1.0
Content-type: multipart/signed; boundary=------------ms090201030106080004050100; micalg=sha1; protocol="application/x-pkcs7-signature"
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Hi,

In section 6.3.3, (b) , RFC3280 states

         (1)  If the DP includes cRLIssuer, then verify that the issuer
         field in the complete CRL matches cRLIssuer in the DP and that
         the complete CRL contains an issuing distribution point
         extension with the indrectCRL boolean asserted.  Otherwise,
         verify that the CRL issuer matches the certificate issuer.

I am interested in a clarification of the "otherwise" case. What test is 
specifically intended to match the CRL issuer to the certificate issuer ?

(a). matching certificate
(b). matching subject
(c). some other entity matching test, and if so, which one ?

It seems to me that (a) can't be the correct test, since even if DP/IDPs 
are not used, both the certificate being verified and the CRL can still 
contain AuthorityKeyID extensions, therefore making the CRL issuer 
certificate distinct from the certificate's issuer certificate.

(b) seems like a good test to require. This is what NSS does today. But 
I can't help but think that it is not sufficient.
If only the issuer subject matches, then technically the CRL issuer 
certificate and certificate issuer certificate could in fact be 
otherwise totally different, even chaining to different roots. This 
would be similar to the case of indirect CRLs, except without the proper 
extensions. Would that be acceptable under RFC3280 ? Is there something 
else I'm missing, perhaps name constraints, that would invalidate this 
case ? It seems to invite some attacks, which I will describe once I 
know the answer to my inquiry.

(c) Hopefully this is the correct answer. Which is the more 
comprehensive matching test to be used in this case ?


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJEzCC
AuQwggJNoAMCAQICAwrRTTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDMwOTI3MDE1MzU5WhcNMDQwOTI2MDE1MzU5
WjBaMQ8wDQYDVQQEEwZQaWVycmUxDzANBgNVBCoTBkp1bGllbjEWMBQGA1UEAxMNSnVsaWVu
IFBpZXJyZTEeMBwGCSqGSIb3DQEJARYPSlBpZXJyZUBhb2wubmV0MIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA0xdg00De1QbRZ+/kEwflzeAaP7dVA8OIAUdXp8xgofWhYiek
4gQPPWovo9uoxMiVskWedcXfyGyjUra85kyPIiU3k/QeAkr2XxSdaU/WjiMBQO5xqcFteo+/
6IhROPhuiMER3o2IZhXu8DFScx7SlNKqiMEdWocFjxIcx0+QOs0IvIp37KaKmHULRLiTnblL
oQ8FjyS950CkTYvrZb5e/hx9k738my6e/DrZqPvmXrOIvagCkB8TJGuSc3Hfn46tFKtx7nd5
p7O+eXQDaXB+GTtpsS3ALI3Fi0Ri+xtf6jFvP2eNjdZ3Y/GnU7/nGcWo+GFIKG9uigLCPoux
zyX4DwIDAQABoywwKjAaBgNVHREEEzARgQ9KUGllcnJlQGFvbC5uZXQwDAYDVR0TAQH/BAIw
ADANBgkqhkiG9w0BAQQFAAOBgQCuWiBtsTmauHTjgdtG5aRee1BouBYn9mRMJxAmaTnfmX21
s93n3UFp0Rbu/mQ+/0HtOb/nwPyJb1zGHMzojDDlgIozTEXMyzLo3XDdXLStK2EtAG9mzyFs
WSUBJEGPoeMuOcwu2CTi2q0scADJJCF0tywF52VsfgdXqmrpTr7pJzCCAuQwggJNoAMCAQIC
AwrRTTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv
bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwHhcNMDMwOTI3MDE1MzU5WhcNMDQwOTI2MDE1MzU5WjBaMQ8wDQYDVQQE
EwZQaWVycmUxDzANBgNVBCoTBkp1bGllbjEWMBQGA1UEAxMNSnVsaWVuIFBpZXJyZTEeMBwG
CSqGSIb3DQEJARYPSlBpZXJyZUBhb2wubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA0xdg00De1QbRZ+/kEwflzeAaP7dVA8OIAUdXp8xgofWhYiek4gQPPWovo9uoxMiV
skWedcXfyGyjUra85kyPIiU3k/QeAkr2XxSdaU/WjiMBQO5xqcFteo+/6IhROPhuiMER3o2I
ZhXu8DFScx7SlNKqiMEdWocFjxIcx0+QOs0IvIp37KaKmHULRLiTnblLoQ8FjyS950CkTYvr
Zb5e/hx9k738my6e/DrZqPvmXrOIvagCkB8TJGuSc3Hfn46tFKtx7nd5p7O+eXQDaXB+GTtp
sS3ALI3Fi0Ri+xtf6jFvP2eNjdZ3Y/GnU7/nGcWo+GFIKG9uigLCPouxzyX4DwIDAQABoyww
KjAaBgNVHREEEzARgQ9KUGllcnJlQGFvbC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B
AQQFAAOBgQCuWiBtsTmauHTjgdtG5aRee1BouBYn9mRMJxAmaTnfmX21s93n3UFp0Rbu/mQ+
/0HtOb/nwPyJb1zGHMzojDDlgIozTEXMyzLo3XDdXLStK2EtAG9mzyFsWSUBJEGPoeMuOcwu
2CTi2q0scADJJCF0tywF52VsfgdXqmrpTr7pJzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN
AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp
ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv
bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD
VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV
cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG
A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy
ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp
dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX
oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx
VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
ggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu
ZyBDQQIDCtFNMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTA0MDIxMjA3MzE0NVowIwYJKoZIhvcNAQkEMRYEFOe+q4jKYZumzrfb
cCfURQ48OuN/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFr
MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMK0U0w
egYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u
c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
SXNzdWluZyBDQQIDCtFNMA0GCSqGSIb3DQEBAQUABIIBAErHsql8xznHi+dJEGeVb7wQgIUR
VnHefb0+B8btRv9MgtU2C9oBsLBolTR7YAbaB3w/pL5MmJirg3G4Rg0gTHqIGUrx2qh313qT
DwXlhtnMeN50pQ50txVW8prpkAN7QWcuNxhOXwRoSv4WKeYo0DY+b3jR6b+nz3Mhwr40FmsE
w5TADMQVp5doe68ugEB1aTVYEnBVKwobbYO4UOJLOG5RWyPajdEiRRpuZOs6qSqIzIEJrRaJ
gI4hsi7xsYOiG+8Z8me7bMzlupb5iH5v8sK8zDiRcVS4V1PBFvbDi4y0YGCQze17WTRaXAcr
/jHOC70P4x3MQmji/ILAgEZ4pSsAAAAAAAA=
--------------ms090201030106080004050100--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1C0XlQX003673; Wed, 11 Feb 2004 16:33:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1C0Xlcf003672; Wed, 11 Feb 2004 16:33:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1C0Xlqq003663 for <[e-mail]>; Wed, 11 Feb 2004 16:33:47 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.10/) with ESMTP id i1C0Y2qW001397 for <[e-mail]>; Wed, 11 Feb 2004 16:34:02 -0800 (PST)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <13JY2PMX>; Wed, 11 Feb 2004 16:34:02 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "Deacon, Alex" <[e-mail]>
Subject: Changes to ocsp.verisign.com
Date: Wed, 11 Feb 2004 16:34:00 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On February 23, 2004, VeriSign will update the OCSP service currently
available at http://ocsp.verisign.com/ to allow for the support of extremely
high transaction volumes.  These changes are being implemented to ensure our
OCSP services continue to scale and perform as new applications and
platforms which support OCSP are introduced into the marketplace.  Note that
this change only effects VeriSign and Thawte retail products including
SSL/TLS and code signing certificates.  Enterprise OCSP services available
at http://onsite-ocsp.verisign.com/ are not effected by this update.

The changes we are making to scale our OCSP responder service will result in
the discontinuation of support for the nonce extension. With this new OCSP
responder service, clients should not expect a nonce in the response to a
request that contains a nonce.

Details regarding responder behavior, how clients can ensure a response is
fresh, additional security considerations and suggested caching behavior has
been documented in an internet-draft co-authored by VeriSign and Microsoft
available at
http://www.ietf.org/internet-drafts/draft-deacon-lightweight-ocsp-profile-00
.txt
 
VeriSign's tests have shown that most of the widely deployed OCSP clients
and toolkits are not effected by this change. However, because our OCSP
services may be used in other applications there is the possibility that
some users may be impacted by this update.

For more information see http://www.verisign.com/support/vendors/ocsp.html 

Regards,

Alex

[e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BNwVlg001708; Wed, 11 Feb 2004 15:58:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BNwV0q001706; Wed, 11 Feb 2004 15:58:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BNwS79001696 for <[e-mail]>; Wed, 11 Feb 2004 15:58:30 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i1BNwhjK032453 for <[e-mail]>; Wed, 11 Feb 2004 18:58:43 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Date: Wed, 11 Feb 2004 18:58:36 -0500
Message-ID: <013f01c3f0fa$f94d5170$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <p06020404bc503eb7365e@[128.33.244.157]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i1BNwU79001701
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

If a CA cross certifies with some domains directly and works with others via
Bridge, that is when the CA should use permitted subtrees and/or excluded
subtrees.

The CA may not wish to communicate with directly cross certified domains via
the Bridge.  In that scenario, the CA can assert excluded subtrees for these
domains as well in the Bridge and/or spell out the permitted domains in the
Bridge (excluding these domains).

In fact the two principal tools a CA has for limiting trust in cross
certified domains are policy mapping and name constraints.  Since in the
Bridge environment, each domain maps their policies to Bridge (using the
certificates they issue to the Bridge) and Bridge in turn maps the policies
to each domain (in the certificates they issue to Bridge).  Thus, domains
can not use the policies to decide selectively which domains it wants to
trust through the Bridge.

Thus, we have two choices in the Bridge model: 1.  Trust all domains cross
certified by the Bridge or 2.  Properly use permitted and excluded subtrees
to trust domains you want to trust.

I am sure PKIs can get messy, but so far the trust domains I have come
across, both permitted and excluded are useful tools.  Neither name
constraint feature is used much due to the usual song and dance of clients
not being able to process the name constraints extensions properly.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Wednesday, February 11, 2004 3:22 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability



At 18:43 -0500 2/10/04, Santosh Chokhani wrote:
>You can also use permitted subtrees in addition to the excluded in a 
>Bridge model.  For example, if the Bridge populated permitted subtree 
>to DN=<domain-n name space> to each PKI  domain-n that it cross 
>certified with, then a domain x could assert (in the certificate it 
>issues to the Bridge) a set of permitted subtrees representing PKI 
>domain name spaces it cares to build trust with.  This should be done 
>in addition to the excluded subtree.
>
>Thus, a PKI cross certifying with a Bridge can select which PKI domains 
>it intends to trust via that Bridge.
>
>Of course, it needs  to trust the Bridge to assert name spaces 
>properly.
>

You make a good point, i.e., there may be an opportunity to use the 
permitted subtrees aspect of the name constraints extension, under 
the right circumstances. However, if a CA directly cross certifies 
some other CAs, and relies on a bridge CA for indirect cross 
certification for others, it will become increasingly messy to keep 
these extensions straight as we try to take maximum advantage of them.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BM8whj093866; Wed, 11 Feb 2004 14:08:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BM8wpu093865; Wed, 11 Feb 2004 14:08:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BM8ukY093856 for <[e-mail]>; Wed, 11 Feb 2004 14:08:57 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1BM95MB003518; Wed, 11 Feb 2004 17:09:06 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020406bc505146795e@[128.89.89.75]>
In-Reply-To: <048f01c3f0e0$96ab86f0$0500a8c0@arport>
References:  <[e-mail]> <048f01c3f0e0$96ab86f0$0500a8c0@arport>
Date: Wed, 11 Feb 2004 16:59:20 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Cc: "Guida, Richard [JJCUS]" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1135585160==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1135585160==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 21:49 +0100 2/11/04, Anders Rundgren wrote:
>Richard,
>before you add this "simple code" 
>(<http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGuide.html>http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGuide.html) 
>you might want to check that your partners are ready for this as 
>well.  I would not be surprised if you rather end-up implementeting 
>a gateway to the bizarre world defined by "morons" like VeriSign, 
>Peter G, and yours truly :-)
>
>Anders
>


Now Anders, despite what others may have said, there is no need to 
openly self-criticize in this way, especially to the extent implied 
by comparing yourself to VeriSign.  After all, when was the last time 
you personally issued a software signing cert to a bogus requester, 
or caused havoc by under provisioning CRL services, etc?

Steve
--============_-1135585160==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Policy User Interfaces (was RE: Setting X.509
Policy D</title></head><body>
<div>At 21:49 +0100 2/11/04, Anders Rundgren wrote:</div>
<blockquote type="cite" cite><font face="Arial"
size="-1">Richard,</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1"><i>before</i> you add this &quot;simple code&quot; (</font><a
href=
"http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGuide.html"><span
></span
>http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPath<span
></span>ProgGuide.html<font face="Arial" size="-1">) you might want to
check that your partners are ready for this as well.&nbsp; I would not
be surprised if you rather end-up implementeting a<i><b>
gateway</b></i> to&nbsp;the bizarre&nbsp;world&nbsp;defined by
&quot;morons&quot; like&nbsp;VeriSign, Peter G, and yours truly
:-)</font></a></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">Anders</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<div><br>
<br>
</div>
<div><font color="#007700">Now<u> Anders, despite what others may have
said, there is no need to openly self-criticize in this way,
especially to the extent implied by comparing yourself to VeriSign.&nbsp;
After all, when was the last time you personally issued a software
signing cert to a bogus requester, or caused havoc by under
provisioning CRL services, etc?</u></font></div>
<div><font color="#007700"><u><br></u></font></div>
<div><font color="#007700"><u>Steve</u></font></div>
</body>
</html>
--============_-1135585160==_ma============--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLtAme092916; Wed, 11 Feb 2004 13:55:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BLtAOG092915; Wed, 11 Feb 2004 13:55:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLt8PM092903 for <[e-mail]>; Wed, 11 Feb 2004 13:55:09 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 11 Feb 2004 22:55:08 +0100
Date: Wed, 11 Feb 2004 22:55:08 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Wed, 11 Feb 2004 21:33:40 +0100 (CET), Richard Levitte - VMS Whacker <[e-mail]> said:

levitte> 
levitte> In message <[e-mail]> on Tue, 3 Feb 2004 10:04:55 -0500, "Al Arsenault" <[e-mail]> said:
levitte> 
levitte> aarsenau> So - is there support (other than Anders and Peter) for
levitte> aarsenau> changing 3280 to make support for Cert Policies optional
levitte> aarsenau> instead of required?
levitte> 
levitte> No.  That would make policies thoroughly unusable, since everyone
levitte> would be able to ignore them anyway (in practice, many still are
levitte> today, but lets look at the future, eh?).

I need to comment on this: policy extension may be marked critical or
may not.  When it's non-critical, it's already optional (as long as
support for certificatePolicies isn't implemented in your software).

So the question is, Al, what exactly are you asking for?  That
certificatePolicies should be possible to ignore even if your software
has implemented support for it?  Some kind of "Extra Non-Critical"
bit?  Sounds like a kludge big time to me.

The way I see it, what you're asking for is already there, just don't
set the critical bit on the cerificatePolicies extension.  Of course,
as someone has already said, that would mean that some software would
consider some invalid paths valid, which is a problem.

Let me ask you this: if your software already supports treatment of
certificatePolicies, why should it avoid handling that extension in a
proper way?  You don't want to insult your programmers by not using
the code they've put joy, tears, blood and whatnot in, do you?

So my answer is still no, mostly because what you ask for is already
there...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLo448092417; Wed, 11 Feb 2004 13:50:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BLo4V6092416; Wed, 11 Feb 2004 13:50:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ncsusraimge05.jnj.com (ncsusraimge05.jnj.com [148.177.2.25]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLo2tb092393 for <[e-mail]>; Wed, 11 Feb 2004 13:50:03 -0800 (PST) (envelope-from [e-mail])
Received: from NCSUSRAWSC6.na.jnj.com (NCSUSRAWSC6.na.jnj.com [10.4.20.26]) by ncsusraimge05.jnj.com (Switch-3.1.2/Switch-3.1.0) with SMTP id i1BLoC7G024151 for <[e-mail]>; Wed, 11 Feb 2004 16:50:12 -0500 (EST)
Received: From NCSUSRAEXIMS1.na.jnj.com ([10.4.20.168]) by NCSUSRAWSC6.na.jnj.com (WebShield SMTP v4.5 MR1a); id 1076536210663; Wed, 11 Feb 2004 16:50:10 -0500
Received: by NCSUSRAEXIMS1.na.jnj.com with Internet Mail Service (5.5.2657.72) id <1401H7C6>; Wed, 11 Feb 2004 16:50:10 -0500
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Date: Wed, 11 Feb 2004 16:50:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F0E8.A730CADC"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

I took it as a given that of course cert path discovery and processing per
DPD/DPV/RFC3280 would first be done (or a relying party trust list would be
managed).  Then the simple "if" conditions would be tested by the relying
party software.  As for bizarre worlds, well, does that not describe
virtually everything we do in information technology?
 


Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  [phone] 

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Wednesday, February 11, 2004 3:50 PM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


Richard,
before you add this "simple code" (
http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGuid
e.html
<http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGui
de.html> ) you might want to check that your partners are ready for this as
well.  I would not be surprised if you rather end-up implementeting a
gateway to the bizarre world defined by "morons" like VeriSign, Peter G, and
yours truly :-)
 
Anders
 

----- Original Message ----- 
From: Guida,  <mailto:[e-mail]> Richard [JJCUS] 
To: 'Anders Rundgren' <mailto:[e-mail]>  ; 'Santosh
<mailto:[e-mail]> Chokhani' ; [e-mail]
<mailto:[e-mail]>  
Sent: Wednesday, February 11, 2004 21:14
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)

Sorry, Anders, but I don't send screen scrapes to anyone.  And you should
not trust me if I did - they are too easily spoofed.  The answer to your
question is: it is not difficult at all to check OIDs under different roots
- a simple "if" conditions suffices.  If Root A and OID A.1, success; if
Root B and OID B.1, success, etc.  We do not yet have a business need to do
so with other CAs, but we see that need arising in the future and are
prepared to deal with it - and in a simple fashion.
 


Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  [phone] 

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Wednesday, February 11, 2004 2:09 PM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


Agnosticism?
Not me!
 
But I seriously doubt that you in your current relying party software are
able to set different policy OIDs per trust anchor which is what your
proposal requires, becuase that would be pretty messy.  In case you really
can, please send me a screen-dump as proof so we finally get all the gory
details of the subject line :-)
 
Regarding non-critical policy extensions I really don't see the point of
having possibly entirely different policies and marking them (or at least
treating them) as non-critical, because that would trick relying party
software into potentially bad trust decisions.  If OTOH the policies are
more or less identical, why not reduce them to just one?
 
But to be frank, we are not at all talking about the same usage scenario
which is the reason TTP CAs stick to one scheme and you and a lot of other
PKIXer promote another scheme.
 
Anders

----- Original Message ----- 
From: Guida,  <mailto:[e-mail]> Richard [JJCUS] 
To: 'Anders Rundgren' <mailto:[e-mail]>  ; 'Santosh
<mailto:[e-mail]> Chokhani' ; [e-mail]
<mailto:[e-mail]>  
Sent: Wednesday, February 11, 2004 16:37
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


Anders - you have not answered the questions I posed.  What is the harm to
you, or anyone else, caused by OIDs in a certPolicies extension that is not
marked critical?  Or, a CA that issues more than one OID?  Separately, I do
not buy your premises.  If I build in the capability (in my relying party
software) to process OIDs, I can accept OIDs put in certs by some other
company's PKI; indeed I would be foolish to just build the capability to
accept my own OIDs (i.e., to hard code my own OIDs with no easy ability to
adjust later).  As for cross-certing, the ability to accept OIDs in some
other entity's certs does NOT require you to cross-cert (of course,
cross-certing with policyMapping may be beneficial, but I'll leave that for
another religious debate at some future time...).  So I again fail to see
the problem here.  You are arguing that some people should not do X; those
people think X is just fine and intend to/are pursuing it; yet you appear to
persist in trying to stop them from doing X when X does not appear to create
any harm to you or others.  I am perplexed by this.  But no need to answer,
I think we have reached the point of agnosticism.  Very best regards -- Rich


Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  [phone] 


-----Original Message----- 
From: Anders Rundgren [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Wednesday, February 11, 2004 2:43 AM 
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [e-mail] 
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data 
in IE, IIS, Outlook) 


Richard,  Santosh et al, 

The only real compromise satisfying those who "believe" in policy 
OIDs and those who don't is to gradually begin deploying CA 
roots supporting a single policy.  That is, if you need another 
policy you should create an additional independent CA root. 

Why?  Community PKIs using multiple policies work just fine 
as long as you: 

1) mainly build your own relying party software. 
2) know that you will only expose the PKI within that specific 
    community. 
3) assume that cross-certification is something that works 
    on a many-to-many basis potentially involving thousands of 
    often volatile business relationships. 

That is, the decision to use multiple policies per CA, MAY prove 
to be a bit problematic in the long run. 

*I* do NOT AT ALL suggest modifying RFC3280, but maybe creating 
a profile and extension explicitly supporting single policy CAs. 

As I have also written numerous times, such schemes offer a 
metadata possibility that can make policies from unknown CAs 
easier to deal with. 

I would be interested to get a list of disadvantages of single- 
policy CAs.  Particularly with respect to relying parties here 
constituting of end-users, administrators and ISVs. 

Anders 


------_=_NextPart_001_01C3F0E8.A730CADC
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in =
IE, IIS, Outlook)</TITLE>

<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D397324721-11022004><FONT face=3DArial =
color=3D#0000ff size=3D2>I took=20
it as a given that of course cert path discovery and&nbsp;processing =
per=20
DPD/DPV/RFC3280 would first be done (or a relying party&nbsp;trust list =
would be=20
managed).&nbsp; Then the simple "if" conditions would be tested by the =
relying=20
party software.&nbsp; As for bizarre worlds, well, does that not =
describe=20
virtually everything we do in information =
technology?</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV><BR>
<P><B><FONT face=3DArial size=3D2>Richard A. Guida</FONT></B> =
<BR><B><FONT=20
face=3DArial size=3D2>Director, Information Security</FONT></B> </P>
<P><B><I><FONT face=3D"Times New Roman" color=3D#ff0000 =
size=3D5>Johnson &amp;=20
Johnson</FONT></I></B><I></I> <BR><FONT face=3DArial size=3D2>Room =
GS8217</FONT>=20
<BR><FONT face=3DArial size=3D2>410 George Street</FONT> <BR><FONT =
face=3DArial=20
size=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT =
face=3DArial=20
size=3D2>Phone:&nbsp; 732 524 3785</FONT> </P>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Anders Rundgren=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, =
February 11,=20
  2004 3:50 PM<BR><B>To:</B> Guida, Richard [JJCUS]; 'Santosh =
Chokhani';=20
  [e-mail]<BR><B>Subject:</B> Re: Policy User Interfaces (was =
RE:=20
  Setting X.509 Policy Data in IE, IIS, Outlook)<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Richard,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><EM>before</EM> you add this "simple =
code" (<A=20
  =
href=3D"http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/Cert=
PathProgGuide.html">http://java.sun.com/j2se/1.4.2/docs/guide/security/c=
ertpath/CertPathProgGuide.html</A>)=20
  you might want to check that your partners are ready for this as =
well.&nbsp; I=20
  would not be surprised if you rather end-up implementeting a=20
  <EM><STRONG>gateway</STRONG></EM> to&nbsp;the =
bizarre&nbsp;world&nbsp;defined=20
  by "morons" like&nbsp;VeriSign, Peter G, and yours truly =
:-)</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=[e-mail] =
href=3D"mailto:[e-mail]">Guida,=20
    Richard [JJCUS]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
    href=3D"mailto:[e-mail]">'Anders Rundgren'</A> ; =
<A=20
    title=[e-mail] =
href=3D"mailto:[e-mail]">'Santosh=20
    Chokhani'</A> ; <A title=[e-mail]=20
    href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, February =
11, 2004=20
    21:14</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Policy User =
Interfaces=20
    (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)</DIV>
    <DIV><BR></DIV>
    <DIV><SPAN class=3D500051120-11022004><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Sorry, Anders, but I don't send screen scrapes to =
anyone.&nbsp; And=20
    you should not trust me if I did - they are too easily spoofed.&nbsp=
; The=20
    answer to your question is: it is not difficult at all to check =
OIDs under=20
    different roots - a simple "if" conditions suffices.&nbsp; If Root =
A and OID=20
    A.1, success; if Root B and OID B.1, success, etc.&nbsp; We do not =
yet have=20
    a business need to do so with other CAs, but we see that need =
arising in the=20
    future and are prepared to deal with it - and in a simple=20
    fashion.</FONT></SPAN></DIV>
    <DIV>&nbsp;</DIV><BR>
    <P><B><FONT face=3DArial size=3D2>Richard A. Guida</FONT></B> =
<BR><B><FONT=20
    face=3DArial size=3D2>Director, Information Security</FONT></B> =
</P>
    <P><B><I><FONT face=3D"Times New Roman" color=3D#ff0000 =
size=3D5>Johnson &amp;=20
    Johnson</FONT></I></B><I></I> <BR><FONT face=3DArial size=3D2>Room =
GS8217</FONT>=20
    <BR><FONT face=3DArial size=3D2>410 George Street</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>Phone:&nbsp; 732 524 3785</FONT> </P>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
      size=3D2>-----Original Message-----<BR><B>From:</B> Anders =
Rundgren=20
      [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, =
February 11,=20
      2004 2:09 PM<BR><B>To:</B> Guida, Richard [JJCUS]; 'Santosh =
Chokhani';=20
      [e-mail]<BR><B>Subject:</B> Re: Policy User Interfaces =
(was RE:=20
      Setting X.509 Policy Data in IE, IIS, =
Outlook)<BR><BR></FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>Agnosticism?</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2>Not me!</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial size=3D2>But I seriously doubt that you =
in your=20
      <EM>current</EM> relying party software are able to set =
<EM>different=20
      policy OIDs&nbsp;per trust anchor</EM> which is what your =
proposal=20
      requires, becuase that&nbsp;would be pretty&nbsp;messy.&nbsp; In =
case you=20
      really can, please send me a screen-dump as proof so we finally =
get all=20
      the gory details of the subject line :-)</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial size=3D2>Regarding non-critical policy =
extensions I=20
      really don't see the point of having possibly entirely different =
policies=20
      and marking them (or at least treating them)&nbsp;as =
non-critical, because=20
      that would trick relying party software into potentially bad =
trust=20
      decisions.&nbsp; If OTOH the policies are more or less identical, =
why=20
      not&nbsp;reduce them&nbsp;to just&nbsp;one?</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial size=3D2>But to be frank, we are not at =
all talking=20
      about the same usage scenario which is the reason&nbsp;TTP =
CAs&nbsp;stick=20
      to one scheme&nbsp;and you and a lot of other PKIXer promote =
another=20
      scheme.</FONT></DIV>
      <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
      <BLOCKQUOTE dir=3Dltr=20
      style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
        <DIV style=3D"FONT: 10pt arial">----- Original Message ----- =
</DIV>
        <DIV=20
        style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
        <A title=[e-mail] =
href=3D"mailto:[e-mail]">Guida,=20
        Richard [JJCUS]</A> </DIV>
        <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
        title=[e-mail]=20
        href=3D"mailto:[e-mail]">'Anders Rundgren'</A> =
; <A=20
        title=[e-mail] =
href=3D"mailto:[e-mail]">'Santosh=20
        Chokhani'</A> ; <A title=[e-mail]=20
        href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
        <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, =
February 11, 2004=20
        16:37</DIV>
        <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Policy User =
Interfaces=20
        (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)</DIV>
        <DIV><BR></DIV>
        <P><FONT size=3D2>Anders - you have not answered the questions =
I=20
        posed.&nbsp; What is the harm to you, or anyone else, caused by =
OIDs in=20
        a certPolicies extension that is not marked critical?&nbsp; Or, =
a CA=20
        that issues more than one OID?&nbsp; Separately, I do not buy =
your=20
        premises.&nbsp; If I build in the capability (in my relying =
party=20
        software) to process OIDs, I can accept OIDs put in certs by =
some other=20
        company's PKI; indeed I would be foolish to just build the =
capability to=20
        accept my own OIDs (i.e., to hard code my own OIDs with no easy =
ability=20
        to adjust later).&nbsp; As for cross-certing, the ability to =
accept OIDs=20
        in some other entity's certs does NOT require you to cross-cert =
(of=20
        course, cross-certing with policyMapping may be beneficial, but =
I'll=20
        leave that for another religious debate at some future =
time...).&nbsp;=20
        So I again fail to see the problem here.&nbsp; You are arguing =
that some=20
        people should not do X; those people think X is just fine and =
intend=20
        to/are pursuing it; yet you appear to persist in trying to stop =
them=20
        from doing X when X does not appear to create any harm to you =
or=20
        others.&nbsp; I am perplexed by this.&nbsp; But no need to =
answer, I=20
        think we have reached the point of agnosticism.&nbsp; Very best =
regards=20
        -- Rich</FONT></P><BR>
        <P><FONT size=3D2>Richard A. Guida</FONT> <BR><FONT =
size=3D2>Director,=20
        Information Security</FONT> </P>
        <P><FONT size=3D2>Johnson &amp; Johnson</FONT> <BR><FONT =
size=3D2>Room=20
        GS8217</FONT> <BR><FONT size=3D2>410 George Street</FONT> =
<BR><FONT=20
        size=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT =

        size=3D2>Phone:&nbsp; 732 524 3785</FONT> </P><BR>
        <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
        Anders Rundgren [<A=20
        =
href=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>=20
        <BR><FONT size=3D2>Sent: Wednesday, February 11, 2004 2:43 =
AM</FONT>=20
        <BR><FONT size=3D2>To: Guida, Richard [JJCUS]; 'Santosh =
Chokhani';=20
        [e-mail]</FONT> <BR><FONT size=3D2>Subject: Re: Policy =
User=20
        Interfaces (was RE: Setting X.509 Policy Data</FONT> <BR><FONT =
size=3D2>in=20
        IE, IIS, Outlook)</FONT> </P><BR>
        <P><FONT size=3D2>Richard,&nbsp; Santosh et al,</FONT> </P>
        <P><FONT size=3D2>The only real compromise satisfying those who =
"believe"=20
        in policy</FONT> <BR><FONT size=3D2>OIDs and those who don't is =
to=20
        gradually begin deploying CA</FONT> <BR><FONT size=3D2>roots =
supporting a=20
        single policy.&nbsp; That is, if you need another</FONT> =
<BR><FONT=20
        size=3D2>policy you should create an additional independent CA=20
        root.</FONT> </P>
        <P><FONT size=3D2>Why?&nbsp; Community PKIs using multiple =
policies work=20
        just fine</FONT> <BR><FONT size=3D2>as long as you:</FONT> </P>
        <P><FONT size=3D2>1) mainly build your own relying party =
software.</FONT>=20
        <BR><FONT size=3D2>2) know that you will only expose the PKI =
within that=20
        specific</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
community.=20
        </FONT><BR><FONT size=3D2>3) assume that cross-certification is =
something=20
        that works</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; on a =
many-to-many=20
        basis potentially involving thousands of</FONT> <BR><FONT=20
        size=3D2>&nbsp;&nbsp;&nbsp; often volatile business =
relationships.</FONT>=20
        </P>
        <P><FONT size=3D2>That is, the decision to use multiple =
policies per CA,=20
        MAY prove</FONT> <BR><FONT size=3D2>to be a bit problematic in =
the long=20
        run.</FONT> </P>
        <P><FONT size=3D2>*I* do NOT AT ALL suggest modifying RFC3280, =
but maybe=20
        creating</FONT> <BR><FONT size=3D2>a profile and extension =
explicitly=20
        supporting single policy CAs.</FONT> </P>
        <P><FONT size=3D2>As I have also written numerous times, such =
schemes=20
        offer a</FONT> <BR><FONT size=3D2>metadata possibility that can =
make=20
        policies from unknown CAs</FONT> <BR><FONT size=3D2>easier to =
deal=20
        with.</FONT> </P>
        <P><FONT size=3D2>I would be interested to get a list of =
disadvantages of=20
        single-</FONT> <BR><FONT size=3D2>policy CAs.&nbsp; =
Particularly with=20
        respect to relying parties here</FONT> <BR><FONT =
size=3D2>constituting of=20
        end-users, administrators and ISVs.</FONT> </P>
        <P><FONT size=3D2>Anders</FONT>=20
</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3F0E8.A730CADC--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLhIb3091945; Wed, 11 Feb 2004 13:43:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BLhIwY091944; Wed, 11 Feb 2004 13:43:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLhGeO091935 for <[e-mail]>; Wed, 11 Feb 2004 13:43:17 -0800 (PST) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i1BLhWi5004008 for <[e-mail]>; Wed, 11 Feb 2004 14:43:32 -0700 (MST)
Received: from sun.com (dhcp-ubur02-75-161.East.Sun.COM [129.148.75.161]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 11 Feb 2004 16:43:31 -0500 (EST)
Date: Wed, 11 Feb 2004 16:41:39 -0500
From: Steve Hanna <[e-mail]>
Subject: Will you support the PKI Action Plan?
To: PKIX List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
Content-type: multipart/signed; boundary=------------msC3B17613BB9A7978AD5E5D37; micalg=sha1; protocol="application/x-pkcs7-signature"
X-Accept-Language: en
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

As you may know, the OASIS PKI Technical Committee
(PKI TC) is working to identify and address the primary
obstacles to PKI deployment and usage. Based on results
from surveys and dialog with PKI stakeholders, the PKI TC
has prepared a PKI Action Plan that lists the obstacles
identified through the surveys and proposes specific
actions to address them.

The PKI Action Plan is available for review from
http://www.oasis-open.org/committees/pki/pkiactionplan.pdf

Executing this PKI Action Plan will require the combined
efforts of many stakeholders: PKI customers, vendors,
standards bodies, and experts. Your help is needed!

If you support this plan, we would ask you to do the
following:

1) Sign on as a supporter of the PKI Action Plan

   Send an email to [e-mail]
   informing us that we can list you as a supporter in
   the PKI Action Plan. Please indicate exactly how you
   would like your endorsement to appear in the Plan
   (e.g., "Dr. Jeremiah Benton, CTO, Big Company, Inc.").

2) Join the PKI Technical Committee or a subcommittee
   working on a specific Action Item in the Plan

   We have formed several subcommittees to implement
   the five Action Items listed in the PKI Action Plan.
   If you would like to join one of these, please contact
   us by email at [e-mail]

3) Ask your employer and/or others to support the Plan

   Ask your employer or another relevant organization to
   endorse the PKI Action Plan. Organizational endorsements
   are especially valuable. Also feel free to pass this
   note on to other people you think would be interested.

By signing on as an early supporter of the PKI Action
Plan, you and your employer will be visible as a leader
in the computer security industry. And of course you will
benefit in years to come as PKI becomes easier to use.

If you have any other comments, suggestions, or
ways in which you can help, feel free to contact us.

We plan to roll out the PKI Action Plan at the
RSA Conference this year. If you will be there,
please join us for a celebratory reception on
Wednesday, February 25, 2004 at 6:00 PM in
Moscone Center North Meeting Room 120. Come
learn more about the PKI Action Plan and help
us celebrate its rollout!

Thanks,

The OASIS PKI Technical Committee

P.S. We recognize that getting permission for an
organizational endorsement or statement of support
will take some time. Don't worry. Endorsements
have already started to roll in. We expect this
to continue throughout the next few months and
in fact throughout the length of the PKI Action Plan.
--------------msC3B17613BB9A7978AD5E5D37
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDQwMjExMjE0MTM5WjAjBgkqhkiG9w0BCQQxFgQUqT3j2OVlmczdviBBLiymkou/
FgMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYANEtUH
dnUbTNNhslQwJfXTXIC2TR4uMW51GIqMXixpKvBsFBw7/L1RyhNo6+EU4qEEh+nm3MhNcBEw
68B9Jgq0OCQlLa3ogeF9xtH53yOn11cqXNqnnOIzl8IuLv258L7BCZmLUOIPp8xYTMxllU2K
2BwU05sTM+d0diF5ju3SDw==
--------------msC3B17613BB9A7978AD5E5D37--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLfYws091778; Wed, 11 Feb 2004 13:41:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BLfYYv091777; Wed, 11 Feb 2004 13:41:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLfWAf091771 for <[e-mail]>; Wed, 11 Feb 2004 13:41:32 -0800 (PST) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i1BLfji9003092 for <[e-mail]>; Wed, 11 Feb 2004 14:41:47 -0700 (MST)
Received: from sun.com (dhcp-ubur02-75-161.East.Sun.COM [129.148.75.161]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 11 Feb 2004 16:41:45 -0500 (EST)
Date: Wed, 11 Feb 2004 16:39:53 -0500
From: Steve Hanna <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE,IIS, Outlook)
To: Al Arsenault <[e-mail]>
Cc: Peter Gutmann <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
Content-type: multipart/signed; boundary=------------msAEA4598C0092803B95115436; micalg=sha1; protocol="application/x-pkcs7-signature"
X-Accept-Language: en
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Al Arsenault wrote:
> So - is there support (other than Anders and Peter) for
> changing 3280 to make support for Cert Policies optional
> instead of required?

No. Implementing support for certificate policies
is not that hard. If a user or application doesn't
want to use policies in their PKI, they don't have to.
But leave in the requirement to implement so that people
who want to use policies can do so using COTS software.

One other thing. We're starting to see RFC 3280
compliant path validation libraries come out.
PLEASE stop moving the target by tweaking the
standards (or proposing to do so). At this point,
we shouldn't change RFC 3280 except for clarifying
things and fixing serious errors. Otherwise, we'll
NEVER get things working.

Thanks,

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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDQwMjExMjEzOTUzWjAjBgkqhkiG9w0BCQQxFgQUMwS2rsjBJWGY8FnZiQZONX/i
pikwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYA2SzCD
0MXsjT1zWBzhZorpplw/gEsRcySHdhN3LPz2K29uMAbM8zbOF/iO3FfConEPO6+iJCKuKv5U
5GrjUTqJbokzDz6+A+szwh1ehqmcRUzPuYmk6adP+caiQvHcaCMMbHet+GPfbx7fbR0y9j/7
dHvS1jRFsk9G8nzgayci7g==
--------------msAEA4598C0092803B95115436--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLWHql090986; Wed, 11 Feb 2004 13:32:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BLWGPG090985; Wed, 11 Feb 2004 13:32:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLWFtB090976 for <[e-mail]>; Wed, 11 Feb 2004 13:32:15 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1BLW8MH001416; Wed, 11 Feb 2004 16:32:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p06020404bc503eb7365e@[128.33.244.157]>
In-Reply-To: <007e01c3f02f$bc277ee0$[e-mail]>
References: <007e01c3f02f$bc277ee0$[e-mail]>
Date: Wed, 11 Feb 2004 15:21:58 -0500
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 18:43 -0500 2/10/04, Santosh Chokhani wrote:
>You can also use permitted subtrees in addition to the excluded in a Bridge
>model.  For example, if the Bridge populated permitted subtree to
>DN=<domain-n name space> to each PKI  domain-n that it cross certified with,
>then a domain x could assert (in the certificate it issues to the Bridge) a
>set of permitted subtrees representing PKI domain name spaces it cares to
>build trust with.  This should be done in addition to the excluded subtree.
>
>Thus, a PKI cross certifying with a Bridge can select which PKI domains it
>intends to trust via that Bridge.
>
>Of course, it needs  to trust the Bridge to assert name spaces properly.
>

You make a good point, i.e., there may be an opportunity to use the 
permitted subtrees aspect of the name constraints extension, under 
the right circumstances. However, if a CA directly cross certifies 
some other CAs, and relies on a bridge CA for indirect cross 
certification for others, it will become increasingly messy to keep 
these extensions straight as we try to take maximum advantage of them.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLW4S5090972; Wed, 11 Feb 2004 13:32:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BLW421090971; Wed, 11 Feb 2004 13:32:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BLW2ut090953 for <[e-mail]>; Wed, 11 Feb 2004 13:32:03 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1BLW8MB001416; Wed, 11 Feb 2004 16:32:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p06020401bc5026741834@[128.33.244.157]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 11 Feb 2004 13:43:45 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 0:12 +1300 2/12/04, [e-mail] wrote:
>"Anders Rundgren" <[e-mail]> writes:
>
>>Well, to update RFC3280 to explicitly support Policy=CA is not really my cup
>>of tea as I believe such an effort would be hard to get support for.
>
>Well, that depends whose support you're talking about.  At the moment the
>majority of CAs are doing just that, so I think it's trivial to get support
>for - it's the other alternative that you'll have trouble convincing the
>masses to use.  OTOH since the market has overwhelmingly voted for this
><cynical>I imagine it'd be hard to get PKIX's support for it, given that
>that'd entail going along with what the users seem to want</cynical>.
>
>Peter (our mail is playing up again, apologies if you see this twice, or not
>        at all).

peter,

It's sometimes hard to tell when you're trying to be sarcastic, vs. 
when your comments are merely so silly that the sarcasm is implied. I 
see that you're using XML to help us know the intent. In this case, 
however, the comment is silly on its face, so the explicit label was 
not needed. so I fear we have lost yet another opportunity to justify 
the use of XML :-)

I'm tempted to view this comment as consistent with the vast majority 
of your comments, which seem to be described as "if a vendor screws 
up in implementing a standard, then if the vendor achieves sufficient 
market share, let's change the standard to match the vendor's screwed 
up implementation."

in the case of policy representation, the lack of use of the feature 
may reflect a lack of need for the feature, or it may simply reflect 
the poor management interfaces provides by vendors that make it hard 
for users (as RPs) to take advantage of the feature, and so both 
users and CAs are forced to use the clunky approach you cite as best 
practice.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BKtalp088359; Wed, 11 Feb 2004 12:55:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BKta0t088358; Wed, 11 Feb 2004 12:55:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-1-sn1.fre.skanova.net (av1-1-sn1.fre.skanova.net [81.228.11.107]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BKtWGP088320 for <[e-mail]>; Wed, 11 Feb 2004 12:55:35 -0800 (PST) (envelope-from [e-mail])
Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id AB6EF37E7D; Wed, 11 Feb 2004 21:55:42 +0100 (CET)
Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id 9D03837E5E for <[e-mail]>; Wed, 11 Feb 2004 21:55:42 +0100 (CET)
Received: from arport (t10o913p13.telia.com [213.64.27.133]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 8F3D937E61; Wed, 11 Feb 2004 21:55:38 +0100 (CET)
Message-ID: <048f01c3f0e0$96ab86f0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Guida, Richard [JJCUS]" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Wed, 11 Feb 2004 21:49:47 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_048A_01C3F0E8.F7DED280"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, =
IIS, Outlook)Richard,
before you add this "simple code" =
(http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProg=
Guide.html) you might want to check that your partners are ready for =
this as well.  I would not be surprised if you rather end-up =
implementeting a gateway to the bizarre world defined by "morons" like =
VeriSign, Peter G, and yours truly :-)

Anders

  ----- Original Message -----=20
  From: Guida, Richard [JJCUS]=20
  To: 'Anders Rundgren' ; 'Santosh Chokhani' ; [e-mail]=20
  Sent: Wednesday, February 11, 2004 21:14
  Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data =
in IE, IIS, Outlook)


  Sorry, Anders, but I don't send screen scrapes to anyone.  And you =
should not trust me if I did - they are too easily spoofed.  The answer =
to your question is: it is not difficult at all to check OIDs under =
different roots - a simple "if" conditions suffices.  If Root A and OID =
A.1, success; if Root B and OID B.1, success, etc.  We do not yet have a =
business need to do so with other CAs, but we see that need arising in =
the future and are prepared to deal with it - and in a simple fashion.



  Richard A. Guida=20
  Director, Information Security=20

  Johnson & Johnson=20
  Room GS8217=20
  410 George Street=20
  New Brunswick, New Jersey  08901=20
  Phone:  [phone]=20

    -----Original Message-----
    From: Anders Rundgren [mailto:[e-mail]]
    Sent: Wednesday, February 11, 2004 2:09 PM
    To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [e-mail]
    Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy =
Data in IE, IIS, Outlook)


    Agnosticism?
    Not me!

    But I seriously doubt that you in your current relying party =
software are able to set different policy OIDs per trust anchor which is =
what your proposal requires, becuase that would be pretty messy.  In =
case you really can, please send me a screen-dump as proof so we finally =
get all the gory details of the subject line :-)

    Regarding non-critical policy extensions I really don't see the =
point of having possibly entirely different policies and marking them =
(or at least treating them) as non-critical, because that would trick =
relying party software into potentially bad trust decisions.  If OTOH =
the policies are more or less identical, why not reduce them to just =
one?

    But to be frank, we are not at all talking about the same usage =
scenario which is the reason TTP CAs stick to one scheme and you and a =
lot of other PKIXer promote another scheme.

    Anders
      ----- Original Message -----=20
      From: Guida, Richard [JJCUS]=20
      To: 'Anders Rundgren' ; 'Santosh Chokhani' ; [e-mail]=20
      Sent: Wednesday, February 11, 2004 16:37
      Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy =
Data in IE, IIS, Outlook)


      Anders - you have not answered the questions I posed.  What is the =
harm to you, or anyone else, caused by OIDs in a certPolicies extension =
that is not marked critical?  Or, a CA that issues more than one OID?  =
Separately, I do not buy your premises.  If I build in the capability =
(in my relying party software) to process OIDs, I can accept OIDs put in =
certs by some other company's PKI; indeed I would be foolish to just =
build the capability to accept my own OIDs (i.e., to hard code my own =
OIDs with no easy ability to adjust later).  As for cross-certing, the =
ability to accept OIDs in some other entity's certs does NOT require you =
to cross-cert (of course, cross-certing with policyMapping may be =
beneficial, but I'll leave that for another religious debate at some =
future time...).  So I again fail to see the problem here.  You are =
arguing that some people should not do X; those people think X is just =
fine and intend to/are pursuing it; yet you appear to persist in trying =
to stop them from doing X when X does not appear to create any harm to =
you or others.  I am perplexed by this.  But no need to answer, I think =
we have reached the point of agnosticism.  Very best regards -- Rich



      Richard A. Guida=20
      Director, Information Security=20

      Johnson & Johnson=20
      Room GS8217=20
      410 George Street=20
      New Brunswick, New Jersey  08901=20
      Phone:  [phone]=20



      -----Original Message-----=20
      From: Anders Rundgren [mailto:[e-mail]]=20
      Sent: Wednesday, February 11, 2004 2:43 AM=20
      To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [e-mail]=20
      Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy =
Data=20
      in IE, IIS, Outlook)=20



      Richard,  Santosh et al,=20

      The only real compromise satisfying those who "believe" in policy=20
      OIDs and those who don't is to gradually begin deploying CA=20
      roots supporting a single policy.  That is, if you need another=20
      policy you should create an additional independent CA root.=20

      Why?  Community PKIs using multiple policies work just fine=20
      as long as you:=20

      1) mainly build your own relying party software.=20
      2) know that you will only expose the PKI within that specific=20
          community.=20
      3) assume that cross-certification is something that works=20
          on a many-to-many basis potentially involving thousands of=20
          often volatile business relationships.=20

      That is, the decision to use multiple policies per CA, MAY prove=20
      to be a bit problematic in the long run.=20

      *I* do NOT AT ALL suggest modifying RFC3280, but maybe creating=20
      a profile and extension explicitly supporting single policy CAs.=20

      As I have also written numerous times, such schemes offer a=20
      metadata possibility that can make policies from unknown CAs=20
      easier to deal with.=20

      I would be interested to get a list of disadvantages of single-=20
      policy CAs.  Particularly with respect to relying parties here=20
      constituting of end-users, administrators and ISVs.=20

      Anders=20

------=_NextPart_000_048A_01C3F0E8.F7DED280
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>RE: Policy User Interfaces (was RE: Setting X.509 =
Policy Data in IE, IIS, Outlook)</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Richard,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><EM>before</EM> you add this "simple =
code" (<A=20
href=3D"http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertP=
athProgGuide.html">http://java.sun.com/j2se/1.4.2/docs/guide/security/cer=
tpath/CertPathProgGuide.html</A>)=20
you might want to check that your partners are ready for this as =
well.&nbsp; I=20
would not be surprised if you rather end-up implementeting a=20
<EM><STRONG>gateway</STRONG></EM> to&nbsp;the =
bizarre&nbsp;world&nbsp;defined by=20
"morons" like&nbsp;VeriSign, Peter G, and yours truly :-)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">Guida,=20
  Richard [JJCUS]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Anders Rundgren'</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">'Santosh=20
  Chokhani'</A> ; <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, February 11, =
2004=20
  21:14</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Policy User =
Interfaces (was=20
  RE: Setting X.509 Policy Data in IE, IIS, Outlook)</DIV>
  <DIV><BR></DIV>
  <DIV><SPAN class=3D500051120-11022004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Sorry, Anders, but I don't send screen scrapes to =
anyone.&nbsp; And you=20
  should not trust me if I did - they are too easily spoofed.&nbsp; The =
answer=20
  to your question is: it is not difficult at all to check OIDs under =
different=20
  roots - a simple "if" conditions suffices.&nbsp; If Root A and OID =
A.1,=20
  success; if Root B and OID B.1, success, etc.&nbsp; We do not yet have =
a=20
  business need to do so with other CAs, but we see that need arising in =
the=20
  future and are prepared to deal with it - and in a simple=20
  fashion.</FONT></SPAN></DIV>
  <DIV>&nbsp;</DIV><BR>
  <P><B><FONT face=3DArial size=3D2>Richard A. Guida</FONT></B> =
<BR><B><FONT=20
  face=3DArial size=3D2>Director, Information Security</FONT></B> </P>
  <P><B><I><FONT face=3D"Times New Roman" color=3D#ff0000 =
size=3D5>Johnson &amp;=20
  Johnson</FONT></I></B><I></I> <BR><FONT face=3DArial size=3D2>Room =
GS8217</FONT>=20
  <BR><FONT face=3DArial size=3D2>410 George Street</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>Phone:&nbsp; 732 524 3785</FONT> </P>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Anders Rundgren=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, =
February 11,=20
    2004 2:09 PM<BR><B>To:</B> Guida, Richard [JJCUS]; 'Santosh =
Chokhani';=20
    [e-mail]<BR><B>Subject:</B> Re: Policy User Interfaces (was =
RE:=20
    Setting X.509 Policy Data in IE, IIS, Outlook)<BR><BR></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Agnosticism?</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Not me!</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>But I seriously doubt that you in =
your=20
    <EM>current</EM> relying party software are able to set =
<EM>different policy=20
    OIDs&nbsp;per trust anchor</EM> which is what your proposal =
requires,=20
    becuase that&nbsp;would be pretty&nbsp;messy.&nbsp; In case you =
really can,=20
    please send me a screen-dump as proof so we finally get all the gory =
details=20
    of the subject line :-)</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Regarding non-critical policy =
extensions I=20
    really don't see the point of having possibly entirely different =
policies=20
    and marking them (or at least treating them)&nbsp;as non-critical, =
because=20
    that would trick relying party software into potentially bad trust=20
    decisions.&nbsp; If OTOH the policies are more or less identical, =
why=20
    not&nbsp;reduce them&nbsp;to just&nbsp;one?</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>But to be frank, we are not at all =
talking=20
    about the same usage scenario which is the reason&nbsp;TTP =
CAs&nbsp;stick to=20
    one scheme&nbsp;and you and a lot of other PKIXer promote another=20
    scheme.</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
      <DIV style=3D"FONT: 10pt arial">----- Original Message ----- =
</DIV>
      <DIV=20
      style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
      <A title=[e-mail] =
href=3D"mailto:[e-mail]">Guida,=20
      Richard [JJCUS]</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
      title=[e-mail]=20
      href=3D"mailto:[e-mail]">'Anders Rundgren'</A> ; =
<A=20
      title=[e-mail] =
href=3D"mailto:[e-mail]">'Santosh=20
      Chokhani'</A> ; <A title=[e-mail]=20
      href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, February =
11, 2004=20
      16:37</DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Policy User =
Interfaces=20
      (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)</DIV>
      <DIV><BR></DIV>
      <P><FONT size=3D2>Anders - you have not answered the questions I=20
      posed.&nbsp; What is the harm to you, or anyone else, caused by =
OIDs in a=20
      certPolicies extension that is not marked critical?&nbsp; Or, a CA =
that=20
      issues more than one OID?&nbsp; Separately, I do not buy your=20
      premises.&nbsp; If I build in the capability (in my relying party=20
      software) to process OIDs, I can accept OIDs put in certs by some =
other=20
      company's PKI; indeed I would be foolish to just build the =
capability to=20
      accept my own OIDs (i.e., to hard code my own OIDs with no easy =
ability to=20
      adjust later).&nbsp; As for cross-certing, the ability to accept =
OIDs in=20
      some other entity's certs does NOT require you to cross-cert (of =
course,=20
      cross-certing with policyMapping may be beneficial, but I'll leave =
that=20
      for another religious debate at some future time...).&nbsp; So I =
again=20
      fail to see the problem here.&nbsp; You are arguing that some =
people=20
      should not do X; those people think X is just fine and intend =
to/are=20
      pursuing it; yet you appear to persist in trying to stop them from =
doing X=20
      when X does not appear to create any harm to you or others.&nbsp; =
I am=20
      perplexed by this.&nbsp; But no need to answer, I think we have =
reached=20
      the point of agnosticism.&nbsp; Very best regards -- =
Rich</FONT></P><BR>
      <P><FONT size=3D2>Richard A. Guida</FONT> <BR><FONT =
size=3D2>Director,=20
      Information Security</FONT> </P>
      <P><FONT size=3D2>Johnson &amp; Johnson</FONT> <BR><FONT =
size=3D2>Room=20
      GS8217</FONT> <BR><FONT size=3D2>410 George Street</FONT> =
<BR><FONT=20
      size=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT=20
      size=3D2>Phone:&nbsp; 732 524 3785</FONT> </P><BR>
      <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
      Anders Rundgren [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]=
m</A>]</FONT>=20
      <BR><FONT size=3D2>Sent: Wednesday, February 11, 2004 2:43 =
AM</FONT>=20
      <BR><FONT size=3D2>To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; =

      [e-mail]</FONT> <BR><FONT size=3D2>Subject: Re: Policy =
User=20
      Interfaces (was RE: Setting X.509 Policy Data</FONT> <BR><FONT =
size=3D2>in=20
      IE, IIS, Outlook)</FONT> </P><BR>
      <P><FONT size=3D2>Richard,&nbsp; Santosh et al,</FONT> </P>
      <P><FONT size=3D2>The only real compromise satisfying those who =
"believe" in=20
      policy</FONT> <BR><FONT size=3D2>OIDs and those who don't is to =
gradually=20
      begin deploying CA</FONT> <BR><FONT size=3D2>roots supporting a =
single=20
      policy.&nbsp; That is, if you need another</FONT> <BR><FONT =
size=3D2>policy=20
      you should create an additional independent CA root.</FONT> </P>
      <P><FONT size=3D2>Why?&nbsp; Community PKIs using multiple =
policies work=20
      just fine</FONT> <BR><FONT size=3D2>as long as you:</FONT> </P>
      <P><FONT size=3D2>1) mainly build your own relying party =
software.</FONT>=20
      <BR><FONT size=3D2>2) know that you will only expose the PKI =
within that=20
      specific</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; community.=20
      </FONT><BR><FONT size=3D2>3) assume that cross-certification is =
something=20
      that works</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; on a =
many-to-many=20
      basis potentially involving thousands of</FONT> <BR><FONT=20
      size=3D2>&nbsp;&nbsp;&nbsp; often volatile business =
relationships.</FONT>=20
      </P>
      <P><FONT size=3D2>That is, the decision to use multiple policies =
per CA, MAY=20
      prove</FONT> <BR><FONT size=3D2>to be a bit problematic in the =
long=20
      run.</FONT> </P>
      <P><FONT size=3D2>*I* do NOT AT ALL suggest modifying RFC3280, but =
maybe=20
      creating</FONT> <BR><FONT size=3D2>a profile and extension =
explicitly=20
      supporting single policy CAs.</FONT> </P>
      <P><FONT size=3D2>As I have also written numerous times, such =
schemes offer=20
      a</FONT> <BR><FONT size=3D2>metadata possibility that can make =
policies from=20
      unknown CAs</FONT> <BR><FONT size=3D2>easier to deal with.</FONT> =
</P>
      <P><FONT size=3D2>I would be interested to get a list of =
disadvantages of=20
      single-</FONT> <BR><FONT size=3D2>policy CAs.&nbsp; Particularly =
with=20
      respect to relying parties here</FONT> <BR><FONT =
size=3D2>constituting of=20
      end-users, administrators and ISVs.</FONT> </P>
      <P><FONT size=3D2>Anders</FONT>=20
</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_048A_01C3F0E8.F7DED280--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BKphVL088145; Wed, 11 Feb 2004 12:51:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BKph0P088144; Wed, 11 Feb 2004 12:51:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BKpfbk088138 for <[e-mail]>; Wed, 11 Feb 2004 12:51:42 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22675; Wed, 11 Feb 2004 15:51:54 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-05.txt
Date: Wed, 11 Feb 2004 15:51:54 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure: Qualified Certificates Profile
	Author(s)	: S. Santesson, M. Nystrom
	Filename	: draft-ietf-pkix-sonof3039-05.txt
	Pages		: 36
	Date		: 2004-2-11
	
This document forms a certificate profile, based on RFC 3280, for
   identity certificates issued to natural persons.

   The profile defines specific conventions for certificates that are
   qualified within a defined legal framework, named Qualified
   Certificates. The profile does however not define any legal
   requirements for such Qualified Certificates.

   The goal of this document is to define a certificate profile that
   supports issuance of Qualified Certificates independent of local
   legal requirements.  The profile is however not limited to Qualified
   Certificates and further profiling may facilitate specific local
   needs.


   The goal of this document is to define a certificate profile that
   supports issuance of Qualified Certificates independent of local
   legal requirements.  The profile is however not limited to Qualified
   Certificates and further profiling may facilitate specific local
   needs.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-sonof3039-05.txt".

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BKpccD088135; Wed, 11 Feb 2004 12:51:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BKpcFm088134; Wed, 11 Feb 2004 12:51:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BKpaRr088126 for <[e-mail]>; Wed, 11 Feb 2004 12:51:37 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22651; Wed, 11 Feb 2004 15:51:49 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-05.txt
Date: Wed, 11 Feb 2004 15:51:49 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure -- Transport Protocols for CMP
	Author(s)	: A. Kapoor, R. Tschalar
	Filename	: draft-ietf-pkix-cmp-transport-protocols-05.txt
	Pages		: 23
	Date		: 2004-2-11
	
This document describes how to layer Certificate Management Protocols
   over various transport protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-05.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmp-transport-protocols-05.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmp-transport-protocols-05.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BKYJwo087171; Wed, 11 Feb 2004 12:34:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BKYJTj087170; Wed, 11 Feb 2004 12:34:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BKYEON087157 for <[e-mail]>; Wed, 11 Feb 2004 12:34:17 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 11 Feb 2004 21:33:42 +0100
Date: Wed, 11 Feb 2004 21:33:40 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Tue, 3 Feb 2004 10:04:55 -0500, "Al Arsenault" <[e-mail]> said:

aarsenau> So - is there support (other than Anders and Peter) for
aarsenau> changing 3280 to make support for Cert Policies optional
aarsenau> instead of required?

No.  That would make policies thoroughly unusable, since everyone
would be able to ignore them anyway (in practice, many still are
today, but lets look at the future, eh?).

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BKEGSa085724; Wed, 11 Feb 2004 12:14:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BKEGOg085723; Wed, 11 Feb 2004 12:14:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ncsusraimge05.jnj.com (ncsusraimge05.jnj.com [148.177.2.25]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BKEEUv085712 for <[e-mail]>; Wed, 11 Feb 2004 12:14:14 -0800 (PST) (envelope-from [e-mail])
Received: from ncsusrawsc10.na.jnj.com (ncsusrawsc10.na.jnj.com [10.4.5.128]) by ncsusraimge05.jnj.com (Switch-3.1.2/Switch-3.1.0) with SMTP id i1BKEN7G004419 for <[e-mail]>; Wed, 11 Feb 2004 15:14:23 -0500 (EST)
Received: From NCSUSRAEXIMS1.na.jnj.com ([10.4.20.168]) by ncsusrawsc10.na.jnj.com (WebShield SMTP v4.5 MR1a); id 1076530453987; Wed, 11 Feb 2004 15:14:13 -0500
Received: by NCSUSRAEXIMS1.na.jnj.com with Internet Mail Service (5.5.2657.72) id <1401G3GM>; Wed, 11 Feb 2004 15:14:13 -0500
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Date: Wed, 11 Feb 2004 15:14:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F0DB.2DE37010"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C3F0DB.2DE37010
Content-Type: text/plain;
	charset="iso-8859-1"

Sorry, Anders, but I don't send screen scrapes to anyone.  And you should
not trust me if I did - they are too easily spoofed.  The answer to your
question is: it is not difficult at all to check OIDs under different roots
- a simple "if" conditions suffices.  If Root A and OID A.1, success; if
Root B and OID B.1, success, etc.  We do not yet have a business need to do
so with other CAs, but we see that need arising in the future and are
prepared to deal with it - and in a simple fashion.
 


Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  [phone] 

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Wednesday, February 11, 2004 2:09 PM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


Agnosticism?
Not me!
 
But I seriously doubt that you in your current relying party software are
able to set different policy OIDs per trust anchor which is what your
proposal requires, becuase that would be pretty messy.  In case you really
can, please send me a screen-dump as proof so we finally get all the gory
details of the subject line :-)
 
Regarding non-critical policy extensions I really don't see the point of
having possibly entirely different policies and marking them (or at least
treating them) as non-critical, because that would trick relying party
software into potentially bad trust decisions.  If OTOH the policies are
more or less identical, why not reduce them to just one?
 
But to be frank, we are not at all talking about the same usage scenario
which is the reason TTP CAs stick to one scheme and you and a lot of other
PKIXer promote another scheme.
 
Anders

----- Original Message ----- 
From: Guida,  <mailto:[e-mail]> Richard [JJCUS] 
To: 'Anders Rundgren' <mailto:[e-mail]>  ; 'Santosh
<mailto:[e-mail]> Chokhani' ; [e-mail]
<mailto:[e-mail]>  
Sent: Wednesday, February 11, 2004 16:37
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


Anders - you have not answered the questions I posed.  What is the harm to
you, or anyone else, caused by OIDs in a certPolicies extension that is not
marked critical?  Or, a CA that issues more than one OID?  Separately, I do
not buy your premises.  If I build in the capability (in my relying party
software) to process OIDs, I can accept OIDs put in certs by some other
company's PKI; indeed I would be foolish to just build the capability to
accept my own OIDs (i.e., to hard code my own OIDs with no easy ability to
adjust later).  As for cross-certing, the ability to accept OIDs in some
other entity's certs does NOT require you to cross-cert (of course,
cross-certing with policyMapping may be beneficial, but I'll leave that for
another religious debate at some future time...).  So I again fail to see
the problem here.  You are arguing that some people should not do X; those
people think X is just fine and intend to/are pursuing it; yet you appear to
persist in trying to stop them from doing X when X does not appear to create
any harm to you or others.  I am perplexed by this.  But no need to answer,
I think we have reached the point of agnosticism.  Very best regards -- Rich


Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  [phone] 


-----Original Message----- 
From: Anders Rundgren [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Wednesday, February 11, 2004 2:43 AM 
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [e-mail] 
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data 
in IE, IIS, Outlook) 


Richard,  Santosh et al, 

The only real compromise satisfying those who "believe" in policy 
OIDs and those who don't is to gradually begin deploying CA 
roots supporting a single policy.  That is, if you need another 
policy you should create an additional independent CA root. 

Why?  Community PKIs using multiple policies work just fine 
as long as you: 

1) mainly build your own relying party software. 
2) know that you will only expose the PKI within that specific 
    community. 
3) assume that cross-certification is something that works 
    on a many-to-many basis potentially involving thousands of 
    often volatile business relationships. 

That is, the decision to use multiple policies per CA, MAY prove 
to be a bit problematic in the long run. 

*I* do NOT AT ALL suggest modifying RFC3280, but maybe creating 
a profile and extension explicitly supporting single policy CAs. 

As I have also written numerous times, such schemes offer a 
metadata possibility that can make policies from unknown CAs 
easier to deal with. 

I would be interested to get a list of disadvantages of single- 
policy CAs.  Particularly with respect to relying parties here 
constituting of end-users, administrators and ISVs. 

Anders 


------_=_NextPart_001_01C3F0DB.2DE37010
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)</TITLE>

<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=500051120-11022004><FONT face=Arial color=#0000ff size=2>Sorry, 
Anders, but I don't send screen scrapes to anyone.&nbsp; And you should not 
trust me if I did - they are too easily spoofed.&nbsp; The answer to your 
question is: it is not difficult at all to check OIDs under different roots - a 
simple "if" conditions suffices.&nbsp; If Root A and OID A.1, success; if Root B 
and OID B.1, success, etc.&nbsp; We do not yet have a business need to do so 
with other CAs, but we see that need arising in the future and are prepared to 
deal with it - and in a simple fashion.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV><BR>
<P><B><FONT face=Arial size=2>Richard A. Guida</FONT></B> <BR><B><FONT 
face=Arial size=2>Director, Information Security</FONT></B> </P>
<P><B><I><FONT face="Times New Roman" color=#ff0000 size=5>Johnson &amp; 
Johnson</FONT></I></B><I></I> <BR><FONT face=Arial size=2>Room GS8217</FONT> 
<BR><FONT face=Arial size=2>410 George Street</FONT> <BR><FONT face=Arial 
size=2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT face=Arial 
size=2>Phone:&nbsp; 732 524 3785</FONT> </P>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Anders Rundgren 
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, February 11, 
  2004 2:09 PM<BR><B>To:</B> Guida, Richard [JJCUS]; 'Santosh Chokhani'; 
  [e-mail]<BR><B>Subject:</B> Re: Policy User Interfaces (was RE: 
  Setting X.509 Policy Data in IE, IIS, Outlook)<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=2>Agnosticism?</FONT></DIV>
  <DIV><FONT face=Arial size=2>Not me!</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>But I seriously doubt that you in your 
  <EM>current</EM> relying party software are able to set <EM>different policy 
  OIDs&nbsp;per trust anchor</EM> which is what your proposal requires, becuase 
  that&nbsp;would be pretty&nbsp;messy.&nbsp; In case you really can, please 
  send me a screen-dump as proof so we finally get all the gory details of the 
  subject line :-)</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Regarding non-critical policy extensions I really 
  don't see the point of having possibly entirely different policies and marking 
  them (or at least treating them)&nbsp;as non-critical, because that would 
  trick relying party software into potentially bad trust decisions.&nbsp; If 
  OTOH the policies are more or less identical, why not&nbsp;reduce them&nbsp;to 
  just&nbsp;one?</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>But to be frank, we are not at all talking about 
  the same usage scenario which is the reason&nbsp;TTP CAs&nbsp;stick to one 
  scheme&nbsp;and you and a lot of other PKIXer promote another 
  scheme.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Anders</FONT></DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
    <A title=[e-mail] href="mailto:[e-mail]">Guida, 
    Richard [JJCUS]</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>To:</B> <A title=[e-mail] 
    href="mailto:[e-mail]">'Anders Rundgren'</A> ; <A 
    title=[e-mail] href="mailto:[e-mail]">'Santosh 
    Chokhani'</A> ; <A title=[e-mail] 
    href="mailto:[e-mail]">[e-mail]</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, February 11, 2004 
    16:37</DIV>
    <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: Policy User Interfaces 
    (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)</DIV>
    <DIV><BR></DIV>
    <P><FONT size=2>Anders - you have not answered the questions I posed.&nbsp; 
    What is the harm to you, or anyone else, caused by OIDs in a certPolicies 
    extension that is not marked critical?&nbsp; Or, a CA that issues more than 
    one OID?&nbsp; Separately, I do not buy your premises.&nbsp; If I build in 
    the capability (in my relying party software) to process OIDs, I can accept 
    OIDs put in certs by some other company's PKI; indeed I would be foolish to 
    just build the capability to accept my own OIDs (i.e., to hard code my own 
    OIDs with no easy ability to adjust later).&nbsp; As for cross-certing, the 
    ability to accept OIDs in some other entity's certs does NOT require you to 
    cross-cert (of course, cross-certing with policyMapping may be beneficial, 
    but I'll leave that for another religious debate at some future 
    time...).&nbsp; So I again fail to see the problem here.&nbsp; You are 
    arguing that some people should not do X; those people think X is just fine 
    and intend to/are pursuing it; yet you appear to persist in trying to stop 
    them from doing X when X does not appear to create any harm to you or 
    others.&nbsp; I am perplexed by this.&nbsp; But no need to answer, I think 
    we have reached the point of agnosticism.&nbsp; Very best regards -- 
    Rich</FONT></P><BR>
    <P><FONT size=2>Richard A. Guida</FONT> <BR><FONT size=2>Director, 
    Information Security</FONT> </P>
    <P><FONT size=2>Johnson &amp; Johnson</FONT> <BR><FONT size=2>Room 
    GS8217</FONT> <BR><FONT size=2>410 George Street</FONT> <BR><FONT size=2>New 
    Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT size=2>Phone:&nbsp; 732 
    524 3785</FONT> </P><BR>
    <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
    Anders Rundgren [<A 
    href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
    <BR><FONT size=2>Sent: Wednesday, February 11, 2004 2:43 AM</FONT> <BR><FONT 
    size=2>To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; 
    [e-mail]</FONT> <BR><FONT size=2>Subject: Re: Policy User 
    Interfaces (was RE: Setting X.509 Policy Data</FONT> <BR><FONT size=2>in IE, 
    IIS, Outlook)</FONT> </P><BR>
    <P><FONT size=2>Richard,&nbsp; Santosh et al,</FONT> </P>
    <P><FONT size=2>The only real compromise satisfying those who "believe" in 
    policy</FONT> <BR><FONT size=2>OIDs and those who don't is to gradually 
    begin deploying CA</FONT> <BR><FONT size=2>roots supporting a single 
    policy.&nbsp; That is, if you need another</FONT> <BR><FONT size=2>policy 
    you should create an additional independent CA root.</FONT> </P>
    <P><FONT size=2>Why?&nbsp; Community PKIs using multiple policies work just 
    fine</FONT> <BR><FONT size=2>as long as you:</FONT> </P>
    <P><FONT size=2>1) mainly build your own relying party software.</FONT> 
    <BR><FONT size=2>2) know that you will only expose the PKI within that 
    specific</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; community. 
    </FONT><BR><FONT size=2>3) assume that cross-certification is something that 
    works</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; on a many-to-many basis 
    potentially involving thousands of</FONT> <BR><FONT 
    size=2>&nbsp;&nbsp;&nbsp; often volatile business relationships.</FONT> </P>
    <P><FONT size=2>That is, the decision to use multiple policies per CA, MAY 
    prove</FONT> <BR><FONT size=2>to be a bit problematic in the long 
    run.</FONT> </P>
    <P><FONT size=2>*I* do NOT AT ALL suggest modifying RFC3280, but maybe 
    creating</FONT> <BR><FONT size=2>a profile and extension explicitly 
    supporting single policy CAs.</FONT> </P>
    <P><FONT size=2>As I have also written numerous times, such schemes offer 
    a</FONT> <BR><FONT size=2>metadata possibility that can make policies from 
    unknown CAs</FONT> <BR><FONT size=2>easier to deal with.</FONT> </P>
    <P><FONT size=2>I would be interested to get a list of disadvantages of 
    single-</FONT> <BR><FONT size=2>policy CAs.&nbsp; Particularly with respect 
    to relying parties here</FONT> <BR><FONT size=2>constituting of end-users, 
    administrators and ISVs.</FONT> </P>
    <P><FONT size=2>Anders</FONT> </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3F0DB.2DE37010--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BJEZxI082438; Wed, 11 Feb 2004 11:14:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BJEZV0082437; Wed, 11 Feb 2004 11:14:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av3-2-sn1.fre.skanova.net (av3-2-sn1.fre.skanova.net [81.228.11.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BJEY2I082422 for <[e-mail]>; Wed, 11 Feb 2004 11:14:34 -0800 (PST) (envelope-from [e-mail])
Received: by av3-2-sn1.fre.skanova.net (Postfix, from userid 502) id 7CF4637E70; Wed, 11 Feb 2004 20:14:43 +0100 (CET)
Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 6E1C537E5B for <[e-mail]>; Wed, 11 Feb 2004 20:14:43 +0100 (CET)
Received: from arport (t11o913p65.telia.com [213.64.28.65]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id A57B937E73; Wed, 11 Feb 2004 20:14:39 +0100 (CET)
Message-ID: <03ae01c3f0d2$7b5014b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Guida, Richard [JJCUS]" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Wed, 11 Feb 2004 20:08:48 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AB_01C3F0DA.DC6ACF30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, =
IIS, Outlook)Agnosticism?
Not me!

But I seriously doubt that you in your current relying party software =
are able to set different policy OIDs per trust anchor which is what =
your proposal requires, becuase that would be pretty messy.  In case you =
really can, please send me a screen-dump as proof so we finally get all =
the gory details of the subject line :-)

Regarding non-critical policy extensions I really don't see the point of =
having possibly entirely different policies and marking them (or at =
least treating them) as non-critical, because that would trick relying =
party software into potentially bad trust decisions.  If OTOH the =
policies are more or less identical, why not reduce them to just one?

But to be frank, we are not at all talking about the same usage scenario =
which is the reason TTP CAs stick to one scheme and you and a lot of =
other PKIXer promote another scheme.

Anders
  ----- Original Message -----=20
  From: Guida, Richard [JJCUS]=20
  To: 'Anders Rundgren' ; 'Santosh Chokhani' ; [e-mail]=20
  Sent: Wednesday, February 11, 2004 16:37
  Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data =
in IE, IIS, Outlook)


  Anders - you have not answered the questions I posed.  What is the =
harm to you, or anyone else, caused by OIDs in a certPolicies extension =
that is not marked critical?  Or, a CA that issues more than one OID?  =
Separately, I do not buy your premises.  If I build in the capability =
(in my relying party software) to process OIDs, I can accept OIDs put in =
certs by some other company's PKI; indeed I would be foolish to just =
build the capability to accept my own OIDs (i.e., to hard code my own =
OIDs with no easy ability to adjust later).  As for cross-certing, the =
ability to accept OIDs in some other entity's certs does NOT require you =
to cross-cert (of course, cross-certing with policyMapping may be =
beneficial, but I'll leave that for another religious debate at some =
future time...).  So I again fail to see the problem here.  You are =
arguing that some people should not do X; those people think X is just =
fine and intend to/are pursuing it; yet you appear to persist in trying =
to stop them from doing X when X does not appear to create any harm to =
you or others.  I am perplexed by this.  But no need to answer, I think =
we have reached the point of agnosticism.  Very best regards -- Rich



  Richard A. Guida=20
  Director, Information Security=20

  Johnson & Johnson=20
  Room GS8217=20
  410 George Street=20
  New Brunswick, New Jersey  08901=20
  Phone:  [phone]=20



  -----Original Message-----=20
  From: Anders Rundgren [mailto:[e-mail]]=20
  Sent: Wednesday, February 11, 2004 2:43 AM=20
  To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [e-mail]=20
  Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data =

  in IE, IIS, Outlook)=20



  Richard,  Santosh et al,=20

  The only real compromise satisfying those who "believe" in policy=20
  OIDs and those who don't is to gradually begin deploying CA=20
  roots supporting a single policy.  That is, if you need another=20
  policy you should create an additional independent CA root.=20

  Why?  Community PKIs using multiple policies work just fine=20
  as long as you:=20

  1) mainly build your own relying party software.=20
  2) know that you will only expose the PKI within that specific=20
      community.=20
  3) assume that cross-certification is something that works=20
      on a many-to-many basis potentially involving thousands of=20
      often volatile business relationships.=20

  That is, the decision to use multiple policies per CA, MAY prove=20
  to be a bit problematic in the long run.=20

  *I* do NOT AT ALL suggest modifying RFC3280, but maybe creating=20
  a profile and extension explicitly supporting single policy CAs.=20

  As I have also written numerous times, such schemes offer a=20
  metadata possibility that can make policies from unknown CAs=20
  easier to deal with.=20

  I would be interested to get a list of disadvantages of single-=20
  policy CAs.  Particularly with respect to relying parties here=20
  constituting of end-users, administrators and ISVs.=20

  Anders=20

------=_NextPart_000_03AB_01C3F0DA.DC6ACF30
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>RE: Policy User Interfaces (was RE: Setting X.509 =
Policy Data in IE, IIS, Outlook)</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Agnosticism?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Not me!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>But I seriously doubt that you in your=20
<EM>current</EM> relying party software are able to set <EM>different =
policy=20
OIDs&nbsp;per trust anchor</EM> which is what your proposal requires, =
becuase=20
that&nbsp;would be pretty&nbsp;messy.&nbsp; In case you really can, =
please send=20
me a screen-dump as proof so we finally get all the gory details of the =
subject=20
line :-)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regarding non-critical policy =
extensions I really=20
don't see the point of having possibly entirely different policies and =
marking=20
them (or at least treating them)&nbsp;as non-critical, because that =
would trick=20
relying party software into potentially bad trust decisions.&nbsp; If =
OTOH the=20
policies are more or less identical, why not&nbsp;reduce them&nbsp;to=20
just&nbsp;one?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>But to be frank, we are not at all =
talking about=20
the same usage scenario which is the reason&nbsp;TTP CAs&nbsp;stick to =
one=20
scheme&nbsp;and you and a lot of other PKIXer promote another=20
scheme.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">Guida,=20
  Richard [JJCUS]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Anders Rundgren'</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">'Santosh=20
  Chokhani'</A> ; <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, February 11, =
2004=20
  16:37</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Policy User =
Interfaces (was=20
  RE: Setting X.509 Policy Data in IE, IIS, Outlook)</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>Anders - you have not answered the questions I =
posed.&nbsp;=20
  What is the harm to you, or anyone else, caused by OIDs in a =
certPolicies=20
  extension that is not marked critical?&nbsp; Or, a CA that issues more =
than=20
  one OID?&nbsp; Separately, I do not buy your premises.&nbsp; If I =
build in the=20
  capability (in my relying party software) to process OIDs, I can =
accept OIDs=20
  put in certs by some other company's PKI; indeed I would be foolish to =
just=20
  build the capability to accept my own OIDs (i.e., to hard code my own =
OIDs=20
  with no easy ability to adjust later).&nbsp; As for cross-certing, the =
ability=20
  to accept OIDs in some other entity's certs does NOT require you to =
cross-cert=20
  (of course, cross-certing with policyMapping may be beneficial, but =
I'll leave=20
  that for another religious debate at some future time...).&nbsp; So I =
again=20
  fail to see the problem here.&nbsp; You are arguing that some people =
should=20
  not do X; those people think X is just fine and intend to/are pursuing =
it; yet=20
  you appear to persist in trying to stop them from doing X when X does =
not=20
  appear to create any harm to you or others.&nbsp; I am perplexed by=20
  this.&nbsp; But no need to answer, I think we have reached the point =
of=20
  agnosticism.&nbsp; Very best regards -- Rich</FONT></P><BR>
  <P><FONT size=3D2>Richard A. Guida</FONT> <BR><FONT size=3D2>Director, =
Information=20
  Security</FONT> </P>
  <P><FONT size=3D2>Johnson &amp; Johnson</FONT> <BR><FONT size=3D2>Room =

  GS8217</FONT> <BR><FONT size=3D2>410 George Street</FONT> <BR><FONT =
size=3D2>New=20
  Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT =
size=3D2>Phone:&nbsp; 732 524=20
  3785</FONT> </P><BR>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Anders Rundgren [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]=
m</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Wednesday, February 11, 2004 2:43 AM</FONT> =
<BR><FONT=20
  size=3D2>To: Guida, Richard [JJCUS]; 'Santosh Chokhani';=20
  [e-mail]</FONT> <BR><FONT size=3D2>Subject: Re: Policy User =
Interfaces=20
  (was RE: Setting X.509 Policy Data</FONT> <BR><FONT size=3D2>in IE, =
IIS,=20
  Outlook)</FONT> </P><BR>
  <P><FONT size=3D2>Richard,&nbsp; Santosh et al,</FONT> </P>
  <P><FONT size=3D2>The only real compromise satisfying those who =
"believe" in=20
  policy</FONT> <BR><FONT size=3D2>OIDs and those who don't is to =
gradually begin=20
  deploying CA</FONT> <BR><FONT size=3D2>roots supporting a single =
policy.&nbsp;=20
  That is, if you need another</FONT> <BR><FONT size=3D2>policy you =
should create=20
  an additional independent CA root.</FONT> </P>
  <P><FONT size=3D2>Why?&nbsp; Community PKIs using multiple policies =
work just=20
  fine</FONT> <BR><FONT size=3D2>as long as you:</FONT> </P>
  <P><FONT size=3D2>1) mainly build your own relying party =
software.</FONT>=20
  <BR><FONT size=3D2>2) know that you will only expose the PKI within =
that=20
  specific</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; community.=20
  </FONT><BR><FONT size=3D2>3) assume that cross-certification is =
something that=20
  works</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; on a many-to-many =
basis=20
  potentially involving thousands of</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  often volatile business relationships.</FONT> </P>
  <P><FONT size=3D2>That is, the decision to use multiple policies per =
CA, MAY=20
  prove</FONT> <BR><FONT size=3D2>to be a bit problematic in the long =
run.</FONT>=20
  </P>
  <P><FONT size=3D2>*I* do NOT AT ALL suggest modifying RFC3280, but =
maybe=20
  creating</FONT> <BR><FONT size=3D2>a profile and extension explicitly =
supporting=20
  single policy CAs.</FONT> </P>
  <P><FONT size=3D2>As I have also written numerous times, such schemes =
offer=20
  a</FONT> <BR><FONT size=3D2>metadata possibility that can make =
policies from=20
  unknown CAs</FONT> <BR><FONT size=3D2>easier to deal with.</FONT> </P>
  <P><FONT size=3D2>I would be interested to get a list of disadvantages =
of=20
  single-</FONT> <BR><FONT size=3D2>policy CAs.&nbsp; Particularly with =
respect to=20
  relying parties here</FONT> <BR><FONT size=3D2>constituting of =
end-users,=20
  administrators and ISVs.</FONT> </P>
  <P><FONT size=3D2>Anders</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_03AB_01C3F0DA.DC6ACF30--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BFsp92066566; Wed, 11 Feb 2004 07:54:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BFspxq066564; Wed, 11 Feb 2004 07:54:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av3-1-sn1.fre.skanova.net (av3-1-sn1.fre.skanova.net [81.228.11.109]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BFsoJo066545 for <[e-mail]>; Wed, 11 Feb 2004 07:54:50 -0800 (PST) (envelope-from [e-mail])
Received: by av3-1-sn1.fre.skanova.net (Postfix, from userid 502) id 7F0E537E5F; Wed, 11 Feb 2004 16:54:59 +0100 (CET)
Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av3-1-sn1.fre.skanova.net (Postfix) with ESMTP id 734F637E4C for <[e-mail]>; Wed, 11 Feb 2004 16:54:59 +0100 (CET)
Received: from arport (t7o913p120.telia.com [213.64.26.120]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 5354037E70; Wed, 11 Feb 2004 16:54:56 +0100 (CET)
Message-ID: <032b01c3f0b6$95313510$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Al Arsenault" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Wed, 11 Feb 2004 16:49:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Al,

>> I claim that current PKIX standards poorly support such scenarios
>> as they have primarily been designed with "owners" in mind.

>Huh?  I'm lost.  "Many-to-many PKI-secured communication comprising hundreds
>or may thousands of uncoordinate PKIs, where som are TTPs and others are
>in-house."  What the heck is that supposed to mean?

OK, I'll give it a try.  In the current non-PKI enabled world we carry
out business using not perfectly secure methods such as snail-mail,
phones, e-mail and to some extent personal contacts.  A common
characteristic of these communication methods is that they require
negligible technical competence of the parties involved. 
The relations may be completely transient, to lasting a life-time.
The public generally do not perceive these systems as unreasonable
unsecure.  Callbacks and cross-checking is often performed in case
of doubts in a party's credibility. (why should PKI be any different?)

If we now as an experiment "dress this in PKI", how should it work?
According to your BBN-college Steve, TTPs are in no way
necessary which essentially means that each organization runs
their own CA.  Although Steve is probably a bit optimistic
regarding companies' desire running CAs, some big ones, and
some technology-savvy organizations will surely do that.  That
means indeed that the use-cases you describe below will happen
not once, but pretty often.

However, if this [general purpose communication] scenario requires
cross-certification and policy-mapping, I would say that PKI is toast,
and the venerable userid/password will just live on forever and ever.

Therefore I have suggested two(2) ways to make this scenario
more manageable:

1. Organizations should authenticate on the org (only) level.
   This dramatically reduces the number of "external" CAs needed
   as this level is much better handled by TTPs (in-house CAs who
   claim that "We are what we say we are" is IMHO ridiculous).

2. Improved ways to recognize and administer unknown (but single
    policy) CAs

Both of these proposals have been considerably bashed but the
arguments have IMO been pretty lame as most of the critics 
(unlike you) have not really tried to understand the scenario.

Your description is perfect.  You may indeed occasionally
have to "trust" something you don't know that much about.
Exactly as you do today.  There *will* be mistakes, but
even proper TTP CAs have problems with identity fraud.

But why should this "community" (=world) ever convert to PKI?
I believe that the main benefits would be:
- eliminating the distribution of shared secrets
- having a universal static ID towards all external parties

That is = cutting costs!

regards
Anders

Al's description:

I don't know what "uncoordinated PKIs" are supposed to be, but it sounds
like an inherently bad thing.  If they're not coordinated - which sounds to
me like there's not even a reasonable basis for cross-certification - then
why are they even trying to interact?  There's no basis for sound, reliable
communications.  "I got a signed message.  The signature appeared to
validate, but I have no idea who this person is.  The certificate was
claimed to be signed by CA_X, but I have no idea who CA_X is, or whether
they're authoritative for this person, or what their practices are, or ..."
Sounds to me like the signature is essentially useless.

To give a more concrete example (and apologies to the people I'm picking on,
but...) suppose I got a signed message promising me money from services,
from someone purporting to be "T. Chau" in Hong Kong. Suppose that his
certificate chained back to the "trusted root certificate" that comes along
with IE6 labeled "C&W HKT SecureNet CA Class A". Should I rely on that?
Why?

(And to make it more fun:  "C&W HKT" no longer exists as a company.  HKT was
"Hong Kong Telecom"; they were acquired several years ago by Cable &
Wireless; hence the "C&W".  Then that company was acquired in a leveraged
buyout by Pacific Century CyberWorks, or PCCW.  "SecureNet" was an
Australian company that recently got acquired by beTRUSTed.  (It would take
forever to explain that history.) "SecureNet Asia" was a joint venture in
the Hong Kong region between SecureNet (the Australian company) and PCCW,
and they competed with SecureNet on a number of projects. Parts of PCCW/HKT
were spun into a joint venture with Telstra called CSL, for "Create a Simple
Life" - really.)

So - should I rely on the signature/signed message, in the sense of relying
on it for something monetary? Why?  On what basis? Who owns this CA?  How is
it operated? What standards do they use?

That's my point - I'm hopelessly confused as to what you want here.  Do you
really want "many-to-many PKI-secured communication comprising hundreds or
may thousands of uncoordinate PKIs, where som are TTPs and others are
in-house?"

Al Arsenault





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BFqw0p066393; Wed, 11 Feb 2004 07:52:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BFqvs5066392; Wed, 11 Feb 2004 07:52:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ncsusraimge01.jnj.com (ncsusraimge01.jnj.com [148.177.2.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BFqupe066376 for <[e-mail]>; Wed, 11 Feb 2004 07:52:56 -0800 (PST) (envelope-from [e-mail])
Received: from NCSUSRAWSC2.na.jnj.com (NCSUSRAWSC2.na.jnj.com [10.4.20.22]) by ncsusraimge01.jnj.com (Switch-3.1.2/Switch-3.1.0) with SMTP id i1BFqvNT025889 for <[e-mail]>; Wed, 11 Feb 2004 10:53:02 -0500 (EST)
Received: From ncsusraexims3.rar.ncsus.jnj.com ([150.13.1.35]) by NCSUSRAWSC2.na.jnj.com (WebShield SMTP v4.5 MR1a); id 1076513850615; Wed, 11 Feb 2004 10:37:30 -0500
Received: by ncsusraexims3.rar.ncsus.jnj.com with Internet Mail Service (5.5.2657.72) id <1402LDW0>; Wed, 11 Feb 2004 10:37:29 -0500
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Date: Wed, 11 Feb 2004 10:37:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F0B4.F10665F6"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

Anders - you have not answered the questions I posed.  What is the harm to
you, or anyone else, caused by OIDs in a certPolicies extension that is not
marked critical?  Or, a CA that issues more than one OID?  Separately, I do
not buy your premises.  If I build in the capability (in my relying party
software) to process OIDs, I can accept OIDs put in certs by some other
company's PKI; indeed I would be foolish to just build the capability to
accept my own OIDs (i.e., to hard code my own OIDs with no easy ability to
adjust later).  As for cross-certing, the ability to accept OIDs in some
other entity's certs does NOT require you to cross-cert (of course,
cross-certing with policyMapping may be beneficial, but I'll leave that for
another religious debate at some future time...).  So I again fail to see
the problem here.  You are arguing that some people should not do X; those
people think X is just fine and intend to/are pursuing it; yet you appear to
persist in trying to stop them from doing X when X does not appear to create
any harm to you or others.  I am perplexed by this.  But no need to answer,
I think we have reached the point of agnosticism.  Very best regards -- Rich


Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  [phone]


-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Wednesday, February 11, 2004 2:43 AM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data
in IE, IIS, Outlook)


Richard,  Santosh et al,

The only real compromise satisfying those who "believe" in policy
OIDs and those who don't is to gradually begin deploying CA
roots supporting a single policy.  That is, if you need another
policy you should create an additional independent CA root.

Why?  Community PKIs using multiple policies work just fine
as long as you:

1) mainly build your own relying party software.
2) know that you will only expose the PKI within that specific
    community. 
3) assume that cross-certification is something that works
    on a many-to-many basis potentially involving thousands of
    often volatile business relationships.

That is, the decision to use multiple policies per CA, MAY prove
to be a bit problematic in the long run.

*I* do NOT AT ALL suggest modifying RFC3280, but maybe creating
a profile and extension explicitly supporting single policy CAs.

As I have also written numerous times, such schemes offer a
metadata possibility that can make policies from unknown CAs
easier to deal with.

I would be interested to get a list of disadvantages of single-
policy CAs.  Particularly with respect to relying parties here
constituting of end-users, administrators and ISVs.

Anders

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in =
IE, IIS, Outlook)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Anders - you have not answered the questions I =
posed.&nbsp; What is the harm to you, or anyone else, caused by OIDs in =
a certPolicies extension that is not marked critical?&nbsp; Or, a CA =
that issues more than one OID?&nbsp; Separately, I do not buy your =
premises.&nbsp; If I build in the capability (in my relying party =
software) to process OIDs, I can accept OIDs put in certs by some other =
company's PKI; indeed I would be foolish to just build the capability =
to accept my own OIDs (i.e., to hard code my own OIDs with no easy =
ability to adjust later).&nbsp; As for cross-certing, the ability to =
accept OIDs in some other entity's certs does NOT require you to =
cross-cert (of course, cross-certing with policyMapping may be =
beneficial, but I'll leave that for another religious debate at some =
future time...).&nbsp; So I again fail to see the problem here.&nbsp; =
You are arguing that some people should not do X; those people think X =
is just fine and intend to/are pursuing it; yet you appear to persist =
in trying to stop them from doing X when X does not appear to create =
any harm to you or others.&nbsp; I am perplexed by this.&nbsp; But no =
need to answer, I think we have reached the point of agnosticism.&nbsp; =
Very best regards -- Rich</FONT></P>
<BR>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Security</FONT>
</P>

<P><FONT SIZE=3D2>Johnson &amp; Johnson</FONT>
<BR><FONT SIZE=3D2>Room GS8217</FONT>
<BR><FONT SIZE=3D2>410 George Street</FONT>
<BR><FONT SIZE=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT>
<BR><FONT SIZE=3D2>Phone:&nbsp; 732 524 3785</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, February 11, 2004 2:43 AM</FONT>
<BR><FONT SIZE=3D2>To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Policy User Interfaces (was RE: Setting =
X.509 Policy Data</FONT>
<BR><FONT SIZE=3D2>in IE, IIS, Outlook)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Richard,&nbsp; Santosh et al,</FONT>
</P>

<P><FONT SIZE=3D2>The only real compromise satisfying those who =
&quot;believe&quot; in policy</FONT>
<BR><FONT SIZE=3D2>OIDs and those who don't is to gradually begin =
deploying CA</FONT>
<BR><FONT SIZE=3D2>roots supporting a single policy.&nbsp; That is, if =
you need another</FONT>
<BR><FONT SIZE=3D2>policy you should create an additional independent =
CA root.</FONT>
</P>

<P><FONT SIZE=3D2>Why?&nbsp; Community PKIs using multiple policies =
work just fine</FONT>
<BR><FONT SIZE=3D2>as long as you:</FONT>
</P>

<P><FONT SIZE=3D2>1) mainly build your own relying party =
software.</FONT>
<BR><FONT SIZE=3D2>2) know that you will only expose the PKI within =
that specific</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; community. </FONT>
<BR><FONT SIZE=3D2>3) assume that cross-certification is something that =
works</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; on a many-to-many basis =
potentially involving thousands of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; often volatile business =
relationships.</FONT>
</P>

<P><FONT SIZE=3D2>That is, the decision to use multiple policies per =
CA, MAY prove</FONT>
<BR><FONT SIZE=3D2>to be a bit problematic in the long run.</FONT>
</P>

<P><FONT SIZE=3D2>*I* do NOT AT ALL suggest modifying RFC3280, but =
maybe creating</FONT>
<BR><FONT SIZE=3D2>a profile and extension explicitly supporting single =
policy CAs.</FONT>
</P>

<P><FONT SIZE=3D2>As I have also written numerous times, such schemes =
offer a</FONT>
<BR><FONT SIZE=3D2>metadata possibility that can make policies from =
unknown CAs</FONT>
<BR><FONT SIZE=3D2>easier to deal with.</FONT>
</P>

<P><FONT SIZE=3D2>I would be interested to get a list of disadvantages =
of single-</FONT>
<BR><FONT SIZE=3D2>policy CAs.&nbsp; Particularly with respect to =
relying parties here</FONT>
<BR><FONT SIZE=3D2>constituting of end-users, administrators and =
ISVs.</FONT>
</P>

<P><FONT SIZE=3D2>Anders</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3F0B4.F10665F6--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BEoI4t061641; Wed, 11 Feb 2004 06:50:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BEoIHg061638; Wed, 11 Feb 2004 06:50:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mclean-vscan4.bah.com (mclean-vscan4.bah.com [156.80.3.64]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BEoHVl061622 for <[e-mail]>; Wed, 11 Feb 2004 06:50:17 -0800 (PST) (envelope-from [e-mail])
Received: from mclean-vscan4.bah.com (mclean-vscan4.bah.com [156.80.3.64]) by mclean-vscan4.bah.com (8.11.0/8.11.0) with SMTP id i1BEoKs24300 for <[e-mail]>; Wed, 11 Feb 2004 09:50:20 -0500 (EST)
Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan4.bah.com (NAVGW 2.5.2.12) with SMTP id M2004021109501908353 for <[e-mail]>; Wed, 11 Feb 2004 09:50:19 -0500
Received: from wchokhani ([156.80.128.132]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HSXD7W00.AUK for <[e-mail]>; Wed, 11 Feb 2004 09:50:20 -0500 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Wed, 11 Feb 2004 09:50:18 -0500
Message-ID: <005501c3f0ae$5ec4d700$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <005b01c3f072$a57e9460$0500a8c0@arport>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i1BEoHVl061628
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders:

You can do that now without changing 3280.

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]] 
Sent: Wednesday, February 11, 2004 2:43 AM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


Richard,  Santosh et al,

The only real compromise satisfying those who "believe" in policy OIDs and
those who don't is to gradually begin deploying CA roots supporting a single
policy.  That is, if you need another policy you should create an additional
independent CA root.

Why?  Community PKIs using multiple policies work just fine
as long as you:

1) mainly build your own relying party software.
2) know that you will only expose the PKI within that specific
    community. 
3) assume that cross-certification is something that works
    on a many-to-many basis potentially involving thousands of
    often volatile business relationships.

That is, the decision to use multiple policies per CA, MAY prove to be a bit
problematic in the long run.

*I* do NOT AT ALL suggest modifying RFC3280, but maybe creating a profile
and extension explicitly supporting single policy CAs.

As I have also written numerous times, such schemes offer a metadata
possibility that can make policies from unknown CAs easier to deal with.

I would be interested to get a list of disadvantages of single- policy CAs.
Particularly with respect to relying parties here constituting of end-users,
administrators and ISVs.

Anders




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BEoClx061624; Wed, 11 Feb 2004 06:50:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BEoCRW061623; Wed, 11 Feb 2004 06:50:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BEoBMR061609 for <[e-mail]>; Wed, 11 Feb 2004 06:50:11 -0800 (PST) (envelope-from [e-mail])
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by mclean-vscan1.bah.com (8.11.0/8.11.0) with SMTP id i1BEoI305243 for <[e-mail]>; Wed, 11 Feb 2004 09:50:18 -0500 (EST)
Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan1.bah.com (NAVGW 2.5.2.12) with SMTP id M2004021109501819262 for <[e-mail]>; Wed, 11 Feb 2004 09:50:18 -0500
Received: from wchokhani ([156.80.128.132]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HSXD7V00.QV6 for <[e-mail]>; Wed, 11 Feb 2004 09:50:19 -0500 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data inIE, IIS, Outlook)
Date: Wed, 11 Feb 2004 09:50:18 -0500
Message-ID: <005401c3f0ae$5e22caa0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i1BEoBMR061617
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

You can do that now with any change.  Require explicit policy as path
processing output (vice pass/fail factor) will make this air tight.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, February 11, 2004 6:13 AM
To: [e-mail]; [e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data inIE,
IIS, Outlook)


"Santosh Chokhani" <[e-mail]> writes:

>To All Those who want to simplify 3280 and get rid of policy stuff:

I don't want to get rid of it, I want to make it an option alongside policy=
CA.

>What problems are your applications encountering with the certificates 
>in the area of policy processing?  Specific examples only.

None, because apart from some test certs I've never seen any certs with
policy constraints and mappings and chrome tailfins and all the other stuff.
The problem isn't "policy processing", the problem is that users look at the
spec, see a mass of incomprehensible complexity (and I'm referring
specifically to the incomprehensible policy complexity, not any other
incomprehensible complexity that may or may not be present), and after a lot
of head-scratching go with "policy=CA", never quite sure whether they're
doing the right thing because the spec never comes out and says it's OK, but
it's the only option that makes sense to them.

This fix doesn't involve implementations at all, it makes things simpler for
users with no effect on implementations.

Peter.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BES2hr059260; Wed, 11 Feb 2004 06:28:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BES1iq059259; Wed, 11 Feb 2004 06:28:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BES1fZ059249 for <[e-mail]>; Wed, 11 Feb 2004 06:28:01 -0800 (PST) (envelope-from [e-mail])
Received: from arsenaultd2 (col-dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i1BES9M8001917; Wed, 11 Feb 2004 09:28:09 -0500 (EST)
From: "Al Arsenault" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Wed, 11 Feb 2004 09:28:07 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <023101c3f0a3$39aa3f60$0500a8c0@arport>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Anders Rundgren
> Sent: Wednesday, February 11, 2004 8:31 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data
> in IE, IIS, Outlook)
>

<snip>

> You said what the other guys did not: "an owners perspective".
>
> This is not exactly the same thing as parties involved in
> many-to-many PKI-secured communication comprising hundreds
> or maybe thousands of uncoordinated PKIs, where some are TTPs
> and others are in-house.
>
> I claim that current PKIX standards poorly support such scenarios
> as they have primarly been designed with "owners" in mind.
>

Huh?  I'm lost.  "Many-to-many PKI-secured communication comprising hundreds
or may thousands of uncoordinate PKIs, where som are TTPs and others are
in-house."  What the heck is that supposed to mean?

I don't know what "uncoordinated PKIs" are supposed to be, but it sounds
like an inherently bad thing.  If they're not coordinated - which sounds to
me like there's not even a reasonable basis for cross-certification - then
why are they even trying to interact?  There's no basis for sound, reliable
communications.  "I got a signed message.  The signature appeared to
validate, but I have no idea who this person is.  The certificate was
claimed to be signed by CA_X, but I have no idea who CA_X is, or whether
they're authoritative for this person, or what their practices are, or ..."
Sounds to me like the signature is essentially useless.

To give a more concrete example (and apologies to the people I'm picking on,
but...) suppose I got a signed message promising me money from services,
from someone purporting to be "T. Chau" in Hong Kong. Suppose that his
certificate chained back to the "trusted root certificate" that comes along
with IE6 labeled "C&W HKT SecureNet CA Class A". Should I rely on that?
Why?

(And to make it more fun:  "C&W HKT" no longer exists as a company.  HKT was
"Hong Kong Telecom"; they were acquired several years ago by Cable &
Wireless; hence the "C&W".  Then that company was acquired in a leveraged
buyout by Pacific Century CyberWorks, or PCCW.  "SecureNet" was an
Australian company that recently got acquired by beTRUSTed.  (It would take
forever to explain that history.) "SecureNet Asia" was a joint venture in
the Hong Kong region between SecureNet (the Australian company) and PCCW,
and they competed with SecureNet on a number of projects. Parts of PCCW/HKT
were spun into a joint venture with Telstra called CSL, for "Create a Simple
Life" - really.)

So - should I rely on the signature/signed message, in the sense of relying
on it for something monetary? Why?  On what basis? Who owns this CA?  How is
it operated? What standards do they use?

That's my point - I'm hopelessly confused as to what you want here.  Do you
really want "many-to-many PKI-secured communication comprising hundreds or
may thousands of uncoordinate PKIs, where som are TTPs and others are
in-house?"

			Al Arsenault





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BEJm5a058714; Wed, 11 Feb 2004 06:19:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BEJmJS058713; Wed, 11 Feb 2004 06:19:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BEJkVQ058704 for <[e-mail]>; Wed, 11 Feb 2004 06:19:46 -0800 (PST) (envelope-from [e-mail])
Received: from ng171tdnot45.royalmail.com (unknown [144.87.146.19]) by mail4.consignia.com (Postfix) with ESMTP id 38B5D1225E9; Wed, 11 Feb 2004 14:19:58 +0000 (GMT)
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 11 Feb 2004 14:13:46 +0000
X-MIMETrack: Serialize by Router on m22ng32/H/MTANET(Release 6.5|September 26, 2003) at 11/02/2004 14:19:58
MIME-Version: 1.0
Content-type: multipart/related;  Boundary="0__=8FBBE4A4DFDF960E8f9e8a93df938690918c8FBBE4A4DFDF960E"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=8FBBE4A4DFDF960E8f9e8a93df938690918c8FBBE4A4DFDF960E
Content-type: multipart/alternative; 
	Boundary="1__=8FBBE4A4DFDF960E8f9e8a93df938690918c8FBBE4A4DFDF960E"

--1__=8FBBE4A4DFDF960E8f9e8a93df938690918c8FBBE4A4DFDF960E
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable




Anders,

> I claim that current PKIX standards poorly support such scenarios
> as they have primarily been designed with "owners" in mind.

I support you in that they have been designed such that they permit
the owners to represent themselves in so many different,
inconsistent and sometimes contradictory ways that the end-user
community may struggle to interpret the various and many trust
domains to which they might subscribe.

I have argued in the past for a simplification of PKI and I will
continue to do so. I do not support, however, the addition of
detail that is merely a flavour of something that already exists
within the standards, even if it is a more simplistic and
easy-to-use representation. I favour a narrowing of the range of
plausible valid combinations within the existing rules, which I
believe can accomplish the same thing. I believe the current
standards adequately support 1:N maps between CA and policy and
that there are far greater barriers to widespread PKI uptake (eg.
Lack of unified X.500 naming space) than this.

Regards

Chris



**********************************************************************
This email and any attachments are confidential and intended for the
addressee only. If you are not the named recipient, you must not use,
disclose, reproduce, copy or distribute the contents of this communicat=
ion.
If you have received this in error, please contact the sender and then
delete this email from your system.
**********************************************************************

=

--1__=8FBBE4A4DFDF960E8f9e8a93df938690918c8FBBE4A4DFDF960E
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body><br>
<img src=3D"cid:10__=[e-mail]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for &quot;Anders Rundgr=
en&quot; &lt;[e-mail]&gt;">&quot;Anders Rundgren&quot;=
 &lt;[e-mail]&gt;<br>
<br>
Anders,<br>
<br>
<font face=3D"Courier New">&gt; I claim that current PKIX standards poo=
rly support such scenarios<br>
&gt; as they have primarily been designed with &quot;owners&quot; in mi=
nd.<br>
</font><br>
<font face=3D"Courier New">I support you in that they have been designe=
d such that they permit </font><br>
<font face=3D"Courier New">the owners to represent themselves in so man=
y different, </font><br>
<font face=3D"Courier New">inconsistent and sometimes contradictory way=
s that the end-user </font><br>
<font face=3D"Courier New">community may struggle to interpret the vari=
ous and many trust </font><br>
<font face=3D"Courier New">domains to which they might subscribe.</font=
><br>
<br>
<font face=3D"Courier New">I have argued in the past for a simplificati=
on of PKI and I will </font><br>
<font face=3D"Courier New">continue to do so. I do not support, however=
, the addition of </font><br>
<font face=3D"Courier New">detail that is merely a flavour of something=
 that already exists </font><br>
<font face=3D"Courier New">within the standards, even if it is a more s=
implistic and </font><br>
<font face=3D"Courier New">easy-to-use representation. I favour a narro=
wing of the range of </font><br>
<font face=3D"Courier New">plausible valid combinations within the exis=
ting rules, which I </font><br>
<font face=3D"Courier New">believe can accomplish the same thing. I bel=
ieve the current </font><br>
<font face=3D"Courier New">standards adequately support 1:N maps betwee=
n CA and policy and </font><br>
<font face=3D"Courier New">that there are far greater barriers to wides=
pread PKI uptake (eg. </font><br>
<font face=3D"Courier New">Lack of unified X.500 naming space) than thi=
s.</font><br>
<br>
<font face=3D"Courier New">Regards</font><br>
<br>
<font face=3D"Courier New">Chris</font>


**********************************************************************
This email and any attachments are confidential and intended for the ad=
dressee only. If you are not the named recipient, you must not use, dis=
close, reproduce, copy or distribute the contents of this communication=
. If you have received this in error, please contact the sender and the=
n delete this email from your system.
**********************************************************************


</body></html>=


--1__=8FBBE4A4DFDF960E8f9e8a93df938690918c8FBBE4A4DFDF960E--


--0__=8FBBE4A4DFDF960E8f9e8a93df938690918c8FBBE4A4DFDF960E
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <10__=[e-mail]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4A4DFDF960E8f9e8a93df938690918c8FBBE4A4DFDF960E--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BDaH6I055595; Wed, 11 Feb 2004 05:36:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BDaHn8055594; Wed, 11 Feb 2004 05:36:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av9-1-sn1.fre.skanova.net (av9-1-sn1.fre.skanova.net [81.228.11.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BDaGpF055584 for <[e-mail]>; Wed, 11 Feb 2004 05:36:16 -0800 (PST) (envelope-from [e-mail])
Received: by av9-1-sn1.fre.skanova.net (Postfix, from userid 502) id BB72B37E8A; Wed, 11 Feb 2004 14:36:24 +0100 (CET)
Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av9-1-sn1.fre.skanova.net (Postfix) with ESMTP id A247C37E4C for <[e-mail]>; Wed, 11 Feb 2004 14:36:24 +0100 (CET)
Received: from arport (t10o913p72.telia.com [213.64.27.192]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 849CC37E52; Wed, 11 Feb 2004 14:36:23 +0100 (CET)
Message-ID: <023101c3f0a3$39aa3f60$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Wed, 11 Feb 2004 14:30:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris,

>> I would be interested to get a list of disadvantages of single-
>> policy CAs.

>From an owners perspective, introducing additional CAs merely to
>extend the number of available published policies represents an
>unjustifiable increase in costs and infrastructure complexity
>when the mechanism to support multiple policies per CA already
>exists.

You said what the other guys did not: "an owners perspective".

This is not exactly the same thing as parties involved in 
many-to-many PKI-secured communication comprising hundreds
or maybe thousands of uncoordinated PKIs, where some are TTPs
and others are in-house.

I claim that current PKIX standards poorly support such scenarios
as they have primarly been designed with "owners" in mind.

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BDJ4uE054587; Wed, 11 Feb 2004 05:19:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BDJ4OS054586; Wed, 11 Feb 2004 05:19:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-2-sn1.fre.skanova.net (av7-2-sn1.fre.skanova.net [81.228.11.114]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BDJ2YV054565 for <[e-mail]>; Wed, 11 Feb 2004 05:19:03 -0800 (PST) (envelope-from [e-mail])
Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id 1C68137E78; Wed, 11 Feb 2004 14:19:11 +0100 (CET)
Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id 0F41337E6D for <[e-mail]>; Wed, 11 Feb 2004 14:19:11 +0100 (CET)
Received: from arport (t10o913p72.telia.com [213.64.27.192]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 693DE37E54; Wed, 11 Feb 2004 14:19:06 +0100 (CET)
Message-ID: <021b01c3f0a0$d1827fd0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, "Al Arsenault" <[e-mail]>, "David Kemp" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data inIE, IIS, Outlook)
Date: Wed, 11 Feb 2004 14:13:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

You are perfectly right!

That is, PKIX (or rather the IETF) is unlikely to support anything
new in this area.  Unless it would be associated with additional
complexity maybe? :-)

But ETSI has already done that for PKIX, by defining not less than
three (3)  additional policy-associated elements  (NOT based on
the policy system) that RP applications are supposed to understand
and "filter" on.

I believe that this must have something to do with matching the
perceived high value of qualified certificactes, with a similarly
high cost for relying party users...

Anders

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Wednesday, February 11, 2004 12:12
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data inIE, IIS, Outlook)


"Anders Rundgren" <[e-mail]> writes:

>Well, to update RFC3280 to explicitly support Policy=CA is not really my cup
>of tea as I believe such an effort would be hard to get support for.

Well, that depends whose support you're talking about.  At the moment the
majority of CAs are doing just that, so I think it's trivial to get support
for - it's the other alternative that you'll have trouble convincing the
masses to use.  OTOH since the market has overwhelmingly voted for this
<cynical>I imagine it'd be hard to get PKIX's support for it, given that
that'd entail going along with what the users seem to want</cynical>.

Peter (our mail is playing up again, apologies if you see this twice, or not
       at all).



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BBD49F047055; Wed, 11 Feb 2004 03:13:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BBD4RH047054; Wed, 11 Feb 2004 03:13:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BBD2K4047047 for <[e-mail]>; Wed, 11 Feb 2004 03:13:03 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (csmail.cs.auckland.ac.nz [130.216.33.150]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 441313401C; Thu, 12 Feb 2004 00:11:44 +1300 (NZDT)
Received: from 218-101-47-90.paradise.net.nz (218-101-47-90.paradise.net.nz [218.101.47.90]) by mail.cs.auckland.ac.nz (Horde) with HTTP for <[e-mail]>; Thu, 12 Feb 2004 00:13:11 +1300
Message-ID: <[e-mail]>
Date: Thu, 12 Feb 2004 00:13:11 +1300
From: [e-mail]
To: [e-mail], [e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santosh Chokhani" <[e-mail]> writes:

>To All Those who want to simplify 3280 and get rid of policy stuff:

I don't want to get rid of it, I want to make it an option alongside policy=
CA.

>What problems are your applications encountering with the certificates in the
>area of policy processing?  Specific examples only.

None, because apart from some test certs I've never seen any certs with policy
constraints and mappings and chrome tailfins and all the other stuff.  The
problem isn't "policy processing", the problem is that users look at the spec,
see a mass of incomprehensible complexity (and I'm referring specifically to
the incomprehensible policy complexity, not any other incomprehensible
complexity that may or may not be present), and after a lot of head-scratching
go with "policy=CA", never quite sure whether they're doing the right thing
because the spec never comes out and says it's OK, but it's the only option
that makes sense to them.

This fix doesn't involve implementations at all, it makes things simpler for
users with no effect on implementations.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BBCZEv047028; Wed, 11 Feb 2004 03:12:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BBCZJw047027; Wed, 11 Feb 2004 03:12:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BBCXV1047009 for <[e-mail]>; Wed, 11 Feb 2004 03:12:33 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (csmail.cs.auckland.ac.nz [130.216.33.150]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 958753401C; Thu, 12 Feb 2004 00:11:12 +1300 (NZDT)
Received: from 218-101-47-90.paradise.net.nz (218-101-47-90.paradise.net.nz [218.101.47.90]) by mail.cs.auckland.ac.nz (Horde) with HTTP for <[e-mail]>; Thu, 12 Feb 2004 00:12:39 +1300
Message-ID: <[e-mail]>
Date: Thu, 12 Feb 2004 00:12:39 +1300
From: [e-mail]
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Anders Rundgren" <[e-mail]> writes:

>Well, to update RFC3280 to explicitly support Policy=CA is not really my cup
>of tea as I believe such an effort would be hard to get support for.

Well, that depends whose support you're talking about.  At the moment the
majority of CAs are doing just that, so I think it's trivial to get support
for - it's the other alternative that you'll have trouble convincing the
masses to use.  OTOH since the market has overwhelmingly voted for this
<cynical>I imagine it'd be hard to get PKIX's support for it, given that
that'd entail going along with what the users seem to want</cynical>.

Peter (our mail is playing up again, apologies if you see this twice, or not
       at all).



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BA7uqO040138; Wed, 11 Feb 2004 02:07:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1BA7uAJ040137; Wed, 11 Feb 2004 02:07:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BA7tIC040122 for <[e-mail]>; Wed, 11 Feb 2004 02:07:55 -0800 (PST) (envelope-from [e-mail])
Received: from ng171tdnot45.royalmail.com (unknown [144.87.146.19]) by mail4.consignia.com (Postfix) with ESMTP id 38C321228A6; Wed, 11 Feb 2004 10:06:00 +0000 (GMT)
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 11 Feb 2004 10:04:24 +0000
X-MIMETrack: Serialize by Router on m22ng32/H/MTANET(Release 6.5|September 26, 2003) at 11/02/2004 10:06:00
MIME-Version: 1.0
Content-type: multipart/related;  Boundary="0__=8FBBE4A4DFA489948f9e8a93df938690918c8FBBE4A4DFA48994"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=8FBBE4A4DFA489948f9e8a93df938690918c8FBBE4A4DFA48994
Content-type: multipart/alternative; 
	Boundary="1__=8FBBE4A4DFA489948f9e8a93df938690918c8FBBE4A4DFA48994"

--1__=8FBBE4A4DFA489948f9e8a93df938690918c8FBBE4A4DFA48994
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable




> I would be interested to get a list of disadvantages of single-
> policy CAs.

>From an owners persepctive, introducing additional CAs merely to
extend the number of available published policies represents an
unjustifiable increase in costs and infrastructure complexity
when the mechanism to support multiple policies per CA already
exists.

Chris


**********************************************************************
This email and any attachments are confidential and intended for the
addressee only. If you are not the named recipient, you must not use,
disclose, reproduce, copy or distribute the contents of this communicat=
ion.
If you have received this in error, please contact the sender and then
delete this email from your system.
**********************************************************************

=

--1__=8FBBE4A4DFA489948f9e8a93df938690918c8FBBE4A4DFA48994
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body><br>
<img src=3D"cid:10__=[e-mail]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for &quot;Anders Rundgr=
en&quot; &lt;[e-mail]&gt;">&quot;Anders Rundgren&quot;=
 &lt;[e-mail]&gt;<br>
<br>
<font face=3D"Courier New">&gt; I would be interested to get a list of =
disadvantages of single-<br>
&gt; policy CAs.</font><br>
<br>
<font face=3D"Courier New">From an owners persepctive, introducing addi=
tional CAs merely to</font><br>
<font face=3D"Courier New">extend the number of available published pol=
icies represents an</font><br>
<font face=3D"Courier New">unjustifiable increase in costs and infrastr=
ucture complexity</font><br>
<font face=3D"Courier New">when the mechanism to support multiple polic=
ies per CA already</font><br>
<font face=3D"Courier New">exists.</font><br>
<br>
<font face=3D"Courier New">Chris</font>


**********************************************************************
This email and any attachments are confidential and intended for the ad=
dressee only. If you are not the named recipient, you must not use, dis=
close, reproduce, copy or distribute the contents of this communication=
. If you have received this in error, please contact the sender and the=
n delete this email from your system.
**********************************************************************


</body></html>=


--1__=8FBBE4A4DFA489948f9e8a93df938690918c8FBBE4A4DFA48994--


--0__=8FBBE4A4DFA489948f9e8a93df938690918c8FBBE4A4DFA48994
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <10__=[e-mail]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4A4DFA489948f9e8a93df938690918c8FBBE4A4DFA48994--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1B7meRt092285; Tue, 10 Feb 2004 23:48:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1B7meER092284; Tue, 10 Feb 2004 23:48:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-2-sn1.fre.skanova.net (av1-2-sn1.fre.skanova.net [81.228.11.108]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1B7mcBH092213 for <[e-mail]>; Tue, 10 Feb 2004 23:48:39 -0800 (PST) (envelope-from [e-mail])
Received: by av1-2-sn1.fre.skanova.net (Postfix, from userid 502) id 91A5437E8A; Wed, 11 Feb 2004 08:48:40 +0100 (CET)
Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av1-2-sn1.fre.skanova.net (Postfix) with ESMTP id 856D837E4F for <[e-mail]>; Wed, 11 Feb 2004 08:48:40 +0100 (CET)
Received: from arport (t10o913p44.telia.com [213.64.27.164]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id E6D3F37E44; Wed, 11 Feb 2004 08:48:38 +0100 (CET)
Message-ID: <005b01c3f072$a57e9460$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Guida, Richard [JJCUS]" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Wed, 11 Feb 2004 08:42:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard,  Santosh et al,

The only real compromise satisfying those who "believe" in policy
OIDs and those who don't is to gradually begin deploying CA
roots supporting a single policy.  That is, if you need another
policy you should create an additional independent CA root.

Why?  Community PKIs using multiple policies work just fine
as long as you:

1) mainly build your own relying party software.
2) know that you will only expose the PKI within that specific
    community. 
3) assume that cross-certification is something that works
    on a many-to-many basis potentially involving thousands of
    often volatile business relationships.

That is, the decision to use multiple policies per CA, MAY prove
to be a bit problematic in the long run.

*I* do NOT AT ALL suggest modifying RFC3280, but maybe creating
a profile and extension explicitly supporting single policy CAs.

As I have also written numerous times, such schemes offer a
metadata possibility that can make policies from unknown CAs
easier to deal with.

I would be interested to get a list of disadvantages of single-
policy CAs.  Particularly with respect to relying parties here
constituting of end-users, administrators and ISVs.

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1B17FFc029931; Tue, 10 Feb 2004 17:07:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1B17FXl029930; Tue, 10 Feb 2004 17:07:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ncsusraimge05.jnj.com (ncsusraimge05.jnj.com [148.177.2.25]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1B17DDf029919 for <[e-mail]>; Tue, 10 Feb 2004 17:07:13 -0800 (PST) (envelope-from [e-mail])
Received: from ncsusrawsc10.na.jnj.com (ncsusrawsc10.na.jnj.com [10.4.5.128]) by ncsusraimge05.jnj.com (Switch-3.1.2/Switch-3.1.0) with SMTP id i1B17J7G021848 for <[e-mail]>; Tue, 10 Feb 2004 20:07:19 -0500 (EST)
Received: From NCSUSRAEXIMS1.na.jnj.com ([10.4.20.168]) by ncsusrawsc10.na.jnj.com (WebShield SMTP v4.5 MR1a); id 1076461638357; Tue, 10 Feb 2004 20:07:18 -0500
Received: by NCSUSRAEXIMS1.na.jnj.com with Internet Mail Service (5.5.2657.72) id <140D18QS>; Tue, 10 Feb 2004 20:07:18 -0500
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Date: Tue, 10 Feb 2004 20:07:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F03A.64E8B4CC"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C3F03A.64E8B4CC
Content-Type: text/plain;
	charset="iso-8859-1"

I second Santosh's point.  For those of us who believe policy OIDs will
indeed become an important tool in many regulatory environments at a
minimum, what is wrong with preserving the extension to support such
anticipated uses (which are actually beginning to materialize - at least
within enterprises)?  Is anyone marking the certPolicies extension critical?
If not, then relying party software is free to ignore it.  Policy OIDs for
the masses may be "an OID too far" but policy OIDs in specific communities -
and within enterprises - are useful.  We issue hardware and software
signature certificates but only allow the former for remote access; how do
we tell which is which?  Different policy OIDs in the certPolicies
extension.


Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  [phone]


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Santosh Chokhani
Sent: Tuesday, February 10, 2004 2:11 PM
To: [e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data
in IE, IIS, Outlook)



To All Those who want to simplify 3280 and get rid of policy stuff:

What problems are your applications encountering with the certificates in
the area of policy processing?  Specific examples only.

Based on the knowledge I have of some of the PKIs and based on your
statements that no one wants to use this stuff, and your applications do not
prime the path validation engine with any policy (no pun intended), the only
likely failure I see is the one for require explicit policy.  For that, I
have told X.509 folks that a better design will be to output the value of
require explicit policy to the application without causing a failure.

If that is done and you do not care about policies, certification path
validation engine could be 3280 and X.509 compliant and you can ignore all
policy related inputs and output and go on you merry way doing PKI and
policy geeks can dance with their policy crap.

Sounds like a great solution (not even compromise) to make both camps happy.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jean Pawluk
Sent: Tuesday, February 10, 2004 6:42 AM
To: 'Lars Johansson'; 'Peter Gutmann'
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)



Bravo

 Practical PKI as a goal should to be encouraged as much as possible.

 The sheer complexity and awesome flexibility of the many standards in this
area is limiting the everyday use of PKI technology in new application
areas.

Jean




-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Lars Johansson
Sent: Tuesday, February 10, 2004 3:53 AM
To: Peter Gutmann
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)



Dear list,

Let me add my 0.01 euros to this thread...

Several people have argued that a CA <-> Policy paradigm would be much
simpler for most PKI users (specifically outside the government sector) to
grasp and use. However I object that this paradigm would be the most simple
one. Stated formally, what I claim is the following:

Claim: There exists a PKI paradigm that is simpler than the CA <-> Policy
paradigm. In particular the specific PKI paradigm requires that the
correspondence between CA and Policy mustn't be 1-1 (injective).

Proof: The proof works by giving a counterexample. Consider
an "utopic" world in which all existing CA:s have agreed on a common single
Policy. Clearly this PKI paradigm would be much simpler to grasp and use for
all relying parties in all sectors! However this implies a many-to-one
mapping between CA:s and the single policy, a mapping which is impossible to
achieve with the CA <-> Policy paradigm. QED.

Conclusion: If simplicity is a goal (and I agree that it should) then let's
focus on standardisation of practical certificate- policies which can be
shared by several different CA:s instead of debating wheather policy-OID:s
should exist or not.

That's my opinion! _________________________________________________
Lars Johansson M.Sc.| Consultant
[e-mail] | www.omegapoint.se
phone [phone] | fax [phone]
Omegapoint AB


-------------------
>
> "Al Arsenault" <[e-mail]> writes:
>
> >Okay, then how about the Canadian Government?  See
>
>http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp
>
> The problem is that at the moment we're stuck with having to support
an
> extremely complex and awkward mechanism to accomodate a vanishingly
small
> number of users at the expense of a large majority who don't want to
know or
> care about it, being quite happy with policy=CA.  The "vanishingly
small"
> number currently stands at two, in theory there'd be at least a
third,
> Gatekeeper, but since the government department in charge of it has
had a
> spokesman announce that "I am very grateful for the fact that, at
the moment,
> none of my colleagues has come up with a good use for it. When they
do, I will
> have to do something about it" we'll call it two, and maybe even one 
> eventually depending on whether the Canadian work has reached the
Gatekeeper
> stage yet or not.
>
> >Or maybe just change 3280 to make cert policies optional vice
mandatory, so
> >those people who need policy!=CA but aren't subject to SDN.706 can
still find
> >the information?
>
> Exactly.  So in order to be useful (and applicable) to all users,
the RFC
> could say something like:
>
>   There's an easy way and a hard way to do this.  The easy way
involves
>   CA=policy.  The certificatePolicies MUST contain a single policy
entry with
>   a policy URL or text, MUST NOT contain user notices and notice
numbers and
>   whatnot, and DEFINITELY MUST NOT involve policy constraints,
policy
>   mappings, fuzzy dice, and two-tone paint jobs.  The hard way
involves multi-
>   policy CAs and a lot of Tylenol, for which see the current text.
>
> That way the majority of users can pick the straightforward option
that does
> what they want, and everyone who wants to do it the complex way can
also do
> that.
>
> Peter.
>




------_=_NextPart_001_01C3F03A.64E8B4CC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in =
IE, IIS, Outlook)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I second Santosh's point.&nbsp; For those of us who =
believe policy OIDs will indeed become an important tool in many =
regulatory environments at a minimum, what is wrong with preserving the =
extension to support such anticipated uses (which are actually =
beginning to materialize - at least within enterprises)?&nbsp; Is =
anyone marking the certPolicies extension critical?&nbsp; If not, then =
relying party software is free to ignore it.&nbsp; Policy OIDs for the =
masses may be &quot;an OID too far&quot; but policy OIDs in specific =
communities - and within enterprises - are useful.&nbsp; We issue =
hardware and software signature certificates but only allow the former =
for remote access; how do we tell which is which?&nbsp; Different =
policy OIDs in the certPolicies extension.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Security</FONT>
</P>

<P><FONT SIZE=3D2>Johnson &amp; Johnson</FONT>
<BR><FONT SIZE=3D2>Room GS8217</FONT>
<BR><FONT SIZE=3D2>410 George Street</FONT>
<BR><FONT SIZE=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT>
<BR><FONT SIZE=3D2>Phone:&nbsp; 732 524 3785</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail]</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]On Behalf Of Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, February 10, 2004 2:11 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Policy User Interfaces (was RE: Setting =
X.509 Policy Data</FONT>
<BR><FONT SIZE=3D2>in IE, IIS, Outlook)</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>To All Those who want to simplify 3280 and get rid of =
policy stuff:</FONT>
</P>

<P><FONT SIZE=3D2>What problems are your applications encountering with =
the certificates in</FONT>
<BR><FONT SIZE=3D2>the area of policy processing?&nbsp; Specific =
examples only.</FONT>
</P>

<P><FONT SIZE=3D2>Based on the knowledge I have of some of the PKIs and =
based on your</FONT>
<BR><FONT SIZE=3D2>statements that no one wants to use this stuff, and =
your applications do not</FONT>
<BR><FONT SIZE=3D2>prime the path validation engine with any policy (no =
pun intended), the only</FONT>
<BR><FONT SIZE=3D2>likely failure I see is the one for require explicit =
policy.&nbsp; For that, I</FONT>
<BR><FONT SIZE=3D2>have told X.509 folks that a better design will be =
to output the value of</FONT>
<BR><FONT SIZE=3D2>require explicit policy to the application without =
causing a failure.</FONT>
</P>

<P><FONT SIZE=3D2>If that is done and you do not care about policies, =
certification path</FONT>
<BR><FONT SIZE=3D2>validation engine could be 3280 and X.509 compliant =
and you can ignore all</FONT>
<BR><FONT SIZE=3D2>policy related inputs and output and go on you merry =
way doing PKI and</FONT>
<BR><FONT SIZE=3D2>policy geeks can dance with their policy =
crap.</FONT>
</P>

<P><FONT SIZE=3D2>Sounds like a great solution (not even compromise) to =
make both camps happy.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On</FONT>
<BR><FONT SIZE=3D2>Behalf Of Jean Pawluk</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, February 10, 2004 6:42 AM</FONT>
<BR><FONT SIZE=3D2>To: 'Lars Johansson'; 'Peter Gutmann'</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Policy User Interfaces (was RE: Setting =
X.509 Policy Data in</FONT>
<BR><FONT SIZE=3D2>IE, IIS, Outlook)</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Bravo</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;Practical PKI as a goal should to be encouraged =
as much as possible.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;The sheer complexity and awesome flexibility of =
the many standards in this</FONT>
<BR><FONT SIZE=3D2>area is limiting the everyday use of PKI technology =
in new application</FONT>
<BR><FONT SIZE=3D2>areas.</FONT>
</P>

<P><FONT SIZE=3D2>Jean</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]On</FONT>
<BR><FONT SIZE=3D2>Behalf Of Lars Johansson</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, February 10, 2004 3:53 AM</FONT>
<BR><FONT SIZE=3D2>To: Peter Gutmann</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Policy User Interfaces (was RE: Setting =
X.509 Policy Data in</FONT>
<BR><FONT SIZE=3D2>IE, IIS, Outlook)</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Dear list,</FONT>
</P>

<P><FONT SIZE=3D2>Let me add my 0.01 euros to this thread...</FONT>
</P>

<P><FONT SIZE=3D2>Several people have argued that a CA &lt;-&gt; Policy =
paradigm would be much</FONT>
<BR><FONT SIZE=3D2>simpler for most PKI users (specifically outside the =
government sector) to</FONT>
<BR><FONT SIZE=3D2>grasp and use. However I object that this paradigm =
would be the most simple</FONT>
<BR><FONT SIZE=3D2>one. Stated formally, what I claim is the =
following:</FONT>
</P>

<P><FONT SIZE=3D2>Claim: There exists a PKI paradigm that is simpler =
than the CA &lt;-&gt; Policy</FONT>
<BR><FONT SIZE=3D2>paradigm. In particular the specific PKI paradigm =
requires that the</FONT>
<BR><FONT SIZE=3D2>correspondence between CA and Policy mustn't be 1-1 =
(injective).</FONT>
</P>

<P><FONT SIZE=3D2>Proof: The proof works by giving a counterexample. =
Consider</FONT>
<BR><FONT SIZE=3D2>an &quot;utopic&quot; world in which all existing =
CA:s have agreed on a common single</FONT>
<BR><FONT SIZE=3D2>Policy. Clearly this PKI paradigm would be much =
simpler to grasp and use for</FONT>
<BR><FONT SIZE=3D2>all relying parties in all sectors! However this =
implies a many-to-one</FONT>
<BR><FONT SIZE=3D2>mapping between CA:s and the single policy, a =
mapping which is impossible to</FONT>
<BR><FONT SIZE=3D2>achieve with the CA &lt;-&gt; Policy paradigm. =
QED.</FONT>
</P>

<P><FONT SIZE=3D2>Conclusion: If simplicity is a goal (and I agree that =
it should) then let's</FONT>
<BR><FONT SIZE=3D2>focus on standardisation of practical certificate- =
policies which can be</FONT>
<BR><FONT SIZE=3D2>shared by several different CA:s instead of debating =
wheather policy-OID:s</FONT>
<BR><FONT SIZE=3D2>should exist or not.</FONT>
</P>

<P><FONT SIZE=3D2>That's my opinion! =
_________________________________________________</FONT>
<BR><FONT SIZE=3D2>Lars Johansson M.Sc.| Consultant</FONT>
<BR><FONT SIZE=3D2>[e-mail] | =
www.omegapoint.se</FONT>
<BR><FONT SIZE=3D2>phone [phone] | fax [phone]</FONT>
<BR><FONT SIZE=3D2>Omegapoint AB</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-------------------</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Al Arsenault&quot; =
&lt;[e-mail]&gt; writes:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Okay, then how about the Canadian =
Government?&nbsp; See</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;<A =
HREF=3D"http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e=
.asp" =
TARGET=3D"_blank">http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy=
/aboutCP_e.asp</A></FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The problem is that at the moment we're stuck =
with having to support</FONT>
<BR><FONT SIZE=3D2>an</FONT>
<BR><FONT SIZE=3D2>&gt; extremely complex and awkward mechanism to =
accomodate a vanishingly</FONT>
<BR><FONT SIZE=3D2>small</FONT>
<BR><FONT SIZE=3D2>&gt; number of users at the expense of a large =
majority who don't want to</FONT>
<BR><FONT SIZE=3D2>know or</FONT>
<BR><FONT SIZE=3D2>&gt; care about it, being quite happy with =
policy=3DCA.&nbsp; The &quot;vanishingly</FONT>
<BR><FONT SIZE=3D2>small&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; number currently stands at two, in theory =
there'd be at least a</FONT>
<BR><FONT SIZE=3D2>third,</FONT>
<BR><FONT SIZE=3D2>&gt; Gatekeeper, but since the government department =
in charge of it has</FONT>
<BR><FONT SIZE=3D2>had a</FONT>
<BR><FONT SIZE=3D2>&gt; spokesman announce that &quot;I am very =
grateful for the fact that, at</FONT>
<BR><FONT SIZE=3D2>the moment,</FONT>
<BR><FONT SIZE=3D2>&gt; none of my colleagues has come up with a good =
use for it. When they</FONT>
<BR><FONT SIZE=3D2>do, I will</FONT>
<BR><FONT SIZE=3D2>&gt; have to do something about it&quot; we'll call =
it two, and maybe even one </FONT>
<BR><FONT SIZE=3D2>&gt; eventually depending on whether the Canadian =
work has reached the</FONT>
<BR><FONT SIZE=3D2>Gatekeeper</FONT>
<BR><FONT SIZE=3D2>&gt; stage yet or not.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Or maybe just change 3280 to make cert =
policies optional vice</FONT>
<BR><FONT SIZE=3D2>mandatory, so</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;those people who need policy!=3DCA but =
aren't subject to SDN.706 can</FONT>
<BR><FONT SIZE=3D2>still find</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;the information?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Exactly.&nbsp; So in order to be useful (and =
applicable) to all users,</FONT>
<BR><FONT SIZE=3D2>the RFC</FONT>
<BR><FONT SIZE=3D2>&gt; could say something like:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; There's an easy way and a hard way =
to do this.&nbsp; The easy way</FONT>
<BR><FONT SIZE=3D2>involves</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; CA=3Dpolicy.&nbsp; The =
certificatePolicies MUST contain a single policy</FONT>
<BR><FONT SIZE=3D2>entry with</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; a policy URL or text, MUST NOT =
contain user notices and notice</FONT>
<BR><FONT SIZE=3D2>numbers and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; whatnot, and DEFINITELY MUST NOT =
involve policy constraints,</FONT>
<BR><FONT SIZE=3D2>policy</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; mappings, fuzzy dice, and two-tone =
paint jobs.&nbsp; The hard way</FONT>
<BR><FONT SIZE=3D2>involves multi-</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; policy CAs and a lot of Tylenol, =
for which see the current text.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; That way the majority of users can pick the =
straightforward option</FONT>
<BR><FONT SIZE=3D2>that does</FONT>
<BR><FONT SIZE=3D2>&gt; what they want, and everyone who wants to do it =
the complex way can</FONT>
<BR><FONT SIZE=3D2>also do</FONT>
<BR><FONT SIZE=3D2>&gt; that.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Peter.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C3F03A.64E8B4CC--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1ANheLU024746; Tue, 10 Feb 2004 15:43:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1ANheac024745; Tue, 10 Feb 2004 15:43:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1ANhdN4024739 for <[e-mail]>; Tue, 10 Feb 2004 15:43:39 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i1ANhnjK004193 for <[e-mail]>; Tue, 10 Feb 2004 18:43:50 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Date: Tue, 10 Feb 2004 18:43:44 -0500
Message-ID: <007e01c3f02f$bc277ee0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p06020404bc4eb95deab2@[128.89.89.75]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i1ANhdN4024740
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

You can also use permitted subtrees in addition to the excluded in a Bridge
model.  For example, if the Bridge populated permitted subtree to
DN=<domain-n name space> to each PKI  domain-n that it cross certified with,
then a domain x could assert (in the certificate it issues to the Bridge) a
set of permitted subtrees representing PKI domain name spaces it cares to
build trust with.  This should be done in addition to the excluded subtree.

Thus, a PKI cross certifying with a Bridge can select which PKI domains it
intends to trust via that Bridge.

Of course, it needs  to trust the Bridge to assert name spaces properly.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Tuesday, February 10, 2004 11:39 AM
To: Peter Hesse
Cc: 'Masaki SHIMAOKA'; [e-mail]
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability



At 14:20 -0500 2/3/04, Peter Hesse wrote:
>Shima,
>
>After review, I agree with Denis that any parts of this I-D which the 
>community agrees are useful should be integrated into the existing 
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.tx
>t
>document.  It does not seem that the differences between the introductory
>sections of certpathbuild and this document are worth another entire
>document.  The difference between the documents seems to be solely in the
>level of detail, and I'm not convinced that more detail than what we
>provided in certpathbuild is necessary.
>
>In section 6.2.3 you state that PKIs which participate in a bridge 
>infrastructure should NOT use the nameConstraints extension.  I feel 
>that nameConstraints are a useful if not critical capability in an 
>infrastructure such as this.  With nameConstraints, a participating CA 
>is able to prevent (via excluded subtrees) successful paths from being 
>built to specific certification authorities.
>
>The concept of a unified domain model is new to me, if there is 
>evidence that it is common or worthwhile to cover in the introductory 
>sections of certpathbuild, we can try to arrange that.
>
>I also agree with the comments Denis made below.
>
>--Peter

I agree with Peter's observation about using the excluded subtree 
feature in a bridge CA context.  Although it's a pretty minimal, it's 
the best you can do under this circumstance.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AMCRuI019506; Tue, 10 Feb 2004 14:12:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1AMCRkx019505; Tue, 10 Feb 2004 14:12:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AMCPOK019494 for <[e-mail]>; Tue, 10 Feb 2004 14:12:25 -0800 (PST) (envelope-from [e-mail])
Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1AMBTMJ028527; Tue, 10 Feb 2004 17:12:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p06020404bc4eb95deab2@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 10 Feb 2004 11:38:55 -0500
To: "Peter Hesse" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: "'Masaki SHIMAOKA'" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 14:20 -0500 2/3/04, Peter Hesse wrote:
>Shima,
>
>After review, I agree with Denis that any parts of this I-D which the
>community agrees are useful should be integrated into the existing
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt
>document.  It does not seem that the differences between the introductory
>sections of certpathbuild and this document are worth another entire
>document.  The difference between the documents seems to be solely in the
>level of detail, and I'm not convinced that more detail than what we
>provided in certpathbuild is necessary.
>
>In section 6.2.3 you state that PKIs which participate in a bridge
>infrastructure should NOT use the nameConstraints extension.  I feel that
>nameConstraints are a useful if not critical capability in an infrastructure
>such as this.  With nameConstraints, a participating CA is able to prevent
>(via excluded subtrees) successful paths from being built to specific
>certification authorities.
>
>The concept of a unified domain model is new to me, if there is evidence
>that it is common or worthwhile to cover in the introductory sections of
>certpathbuild, we can try to arrange that.
>
>I also agree with the comments Denis made below.
>
>--Peter

I agree with Peter's observation about using the excluded subtree 
feature in a bridge CA context.  Although it's a pretty minimal, it's 
the best you can do under this circumstance.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AGnPqx017649; Tue, 10 Feb 2004 08:49:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1AGnP8F017648; Tue, 10 Feb 2004 08:49:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (krl9-d9bb4c1d.pool.mediaWays.net [217.187.76.29]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AGnMaU017634 for <[e-mail]>; Tue, 10 Feb 2004 08:49:23 -0800 (PST) (envelope-from [e-mail])
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 326E440DB2 for <[e-mail]>; Tue, 10 Feb 2004 17:44:05 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 10 Feb 2004 17:44:05 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
References: <001301c3efca$dd6c7250$9865fea9@NERVANA3>
In-Reply-To: <001301c3efca$dd6c7250$9865fea9@NERVANA3>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jean Pawluk wrote:
> Bravo
> 
>  Practical PKI as a goal should to be encouraged as much as possible.
> 
>  The sheer complexity and awesome flexibility of the many standards in this
> area is limiting the everyday use of PKI technology in new application
> areas.

Yes.

Ciao, Michael.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AJBSGS007382; Tue, 10 Feb 2004 11:11:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1AJBSdx007378; Tue, 10 Feb 2004 11:11:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AJBROi007369 for <[e-mail]>; Tue, 10 Feb 2004 11:11:27 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i1AJBbjK016165 for <[e-mail]>; Tue, 10 Feb 2004 14:11:37 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Tue, 10 Feb 2004 14:11:29 -0500
Message-ID: <009101c3f009$b51351e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <001301c3efca$dd6c7250$9865fea9@NERVANA3>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i1AJBSOi007371
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To All Those who want to simplify 3280 and get rid of policy stuff:

What problems are your applications encountering with the certificates in
the area of policy processing?  Specific examples only.

Based on the knowledge I have of some of the PKIs and based on your
statements that no one wants to use this stuff, and your applications do not
prime the path validation engine with any policy (no pun intended), the only
likely failure I see is the one for require explicit policy.  For that, I
have told X.509 folks that a better design will be to output the value of
require explicit policy to the application without causing a failure.

If that is done and you do not care about policies, certification path
validation engine could be 3280 and X.509 compliant and you can ignore all
policy related inputs and output and go on you merry way doing PKI and
policy geeks can dance with their policy crap.

Sounds like a great solution (not even compromise) to make both camps happy.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jean Pawluk
Sent: Tuesday, February 10, 2004 6:42 AM
To: 'Lars Johansson'; 'Peter Gutmann'
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)



Bravo

 Practical PKI as a goal should to be encouraged as much as possible.

 The sheer complexity and awesome flexibility of the many standards in this
area is limiting the everyday use of PKI technology in new application
areas.

Jean




-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Lars Johansson
Sent: Tuesday, February 10, 2004 3:53 AM
To: Peter Gutmann
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)



Dear list,

Let me add my 0.01 euros to this thread...

Several people have argued that a CA <-> Policy paradigm would be much
simpler for most PKI users (specifically outside the government sector) to
grasp and use. However I object that this paradigm would be the most simple
one. Stated formally, what I claim is the following:

Claim: There exists a PKI paradigm that is simpler than the CA <-> Policy
paradigm. In particular the specific PKI paradigm requires that the
correspondence between CA and Policy mustn't be 1-1 (injective).

Proof: The proof works by giving a counterexample. Consider
an "utopic" world in which all existing CA:s have agreed on a common single
Policy. Clearly this PKI paradigm would be much simpler to grasp and use for
all relying parties in all sectors! However this implies a many-to-one
mapping between CA:s and the single policy, a mapping which is impossible to
achieve with the CA <-> Policy paradigm. QED.

Conclusion: If simplicity is a goal (and I agree that it should) then let's
focus on standardisation of practical certificate- policies which can be
shared by several different CA:s instead of debating wheather policy-OID:s
should exist or not.

That's my opinion! _________________________________________________
Lars Johansson M.Sc.| Consultant
[e-mail] | www.omegapoint.se
phone [phone] | fax [phone]
Omegapoint AB


-------------------
>
> "Al Arsenault" <[e-mail]> writes:
>
> >Okay, then how about the Canadian Government?  See
>
>http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp
>
> The problem is that at the moment we're stuck with having to support
an
> extremely complex and awkward mechanism to accomodate a vanishingly
small
> number of users at the expense of a large majority who don't want to
know or
> care about it, being quite happy with policy=CA.  The "vanishingly
small"
> number currently stands at two, in theory there'd be at least a
third,
> Gatekeeper, but since the government department in charge of it has
had a
> spokesman announce that "I am very grateful for the fact that, at
the moment,
> none of my colleagues has come up with a good use for it. When they
do, I will
> have to do something about it" we'll call it two, and maybe even one 
> eventually depending on whether the Canadian work has reached the
Gatekeeper
> stage yet or not.
>
> >Or maybe just change 3280 to make cert policies optional vice
mandatory, so
> >those people who need policy!=CA but aren't subject to SDN.706 can
still find
> >the information?
>
> Exactly.  So in order to be useful (and applicable) to all users,
the RFC
> could say something like:
>
>   There's an easy way and a hard way to do this.  The easy way
involves
>   CA=policy.  The certificatePolicies MUST contain a single policy
entry with
>   a policy URL or text, MUST NOT contain user notices and notice
numbers and
>   whatnot, and DEFINITELY MUST NOT involve policy constraints,
policy
>   mappings, fuzzy dice, and two-tone paint jobs.  The hard way
involves multi-
>   policy CAs and a lot of Tylenol, for which see the current text.
>
> That way the majority of users can pick the straightforward option
that does
> what they want, and everyone who wants to do it the complex way can
also do
> that.
>
> Peter.
>






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AEBV3x005639; Tue, 10 Feb 2004 06:11:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1AEBVO3005638; Tue, 10 Feb 2004 06:11:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AEBUHf005631 for <[e-mail]>; Tue, 10 Feb 2004 06:11:30 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t10o913p98.telia.com [213.64.27.218]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id i1AEB5SJ016378; Tue, 10 Feb 2004 15:11:06 +0100 (CET)
Message-ID: <008401c3efde$f1848d40$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Lars Johansson" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Tue, 10 Feb 2004 15:05:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lars,
>From RFC3280:

   "To promote interoperability, this profile RECOMMENDS that policy
    information terms consist of only an OID"

That effectively means that any issuance characteristic including
liability, subject verification method, certificate format, and
usage (web-server, e-mail, etc) are lumped together in a single
blob-like element.

The chance of making such a low-granularity system become
"standard" except for qualified certificates seems pretty slim.

Note: I don't object to the idea of including a policy OID, I just
claim that forward-thinking CA organizations should have separate
roots, etc for each supported policy (OID).  I.e. like VeriSign and
most other TTP CAs.   Because then the interpretation of the Policy
OID becomes redundant and can be left as "decoration" or things to
show legal folks or marketing.

But I cannot really see that my suggestion is in conflict with your
suggestion, Í just want to "cut PKI down to size".

However, adding policy-related metadata to single-policy CA
certificates would in my opinion be a more workable approach
as it does not require competitors to agree on things that they
may not want to.  Such metadata could be something like:
usage=e-mail, liability=zero, subject verification=passport,
hardware key protection=yes

Anders





----- Original Message -----
From: "Lars Johansson" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Tuesday, February 10, 2004 10:53
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)



Dear list,

Let me add my 0.01 euros to this thread...

Several people have argued that a CA <-> Policy paradigm would
be much simpler for most PKI users (specifically outside the
government sector) to grasp and use. However I object that this
paradigm would be the most simple one. Stated formally, what I
claim is the following:

Claim: There exists a PKI paradigm that is simpler than the CA
<-> Policy paradigm. In particular the specific PKI paradigm
requires that the correspondence between CA and Policy mustn't
be 1-1 (injective).

Proof: The proof works by giving a counterexample. Consider
an "utopic" world in which all existing CA:s have agreed on a
common single Policy. Clearly this PKI paradigm would be much
simpler to grasp and use for all relying parties in all sectors!
However this implies a many-to-one mapping between CA:s and the
single policy, a mapping which is impossible to achieve with the
CA <-> Policy paradigm. QED.

Conclusion: If simplicity is a goal (and I agree that it should)
then let's focus on standardisation of practical certificate-
policies which can be shared by several different CA:s instead
of debating wheather policy-OID:s should exist or not.

That's my opinion!
_________________________________________________
Lars Johansson M.Sc.| Consultant
[e-mail] | www.omegapoint.se
phone [phone] | fax [phone]
Omegapoint AB


-------------------
>
> "Al Arsenault" <[e-mail]> writes:
>
> >Okay, then how about the Canadian Government?  See
>
>http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp
>
> The problem is that at the moment we're stuck with having to support
an
> extremely complex and awkward mechanism to accomodate a vanishingly
small
> number of users at the expense of a large majority who don't want to
know or
> care about it, being quite happy with policy=CA.  The "vanishingly
small"
> number currently stands at two, in theory there'd be at least a
third,
> Gatekeeper, but since the government department in charge of it has
had a
> spokesman announce that "I am very grateful for the fact that, at
the moment,
> none of my colleagues has come up with a good use for it. When they
do, I will
> have to do something about it" we'll call it two, and maybe even one
> eventually depending on whether the Canadian work has reached the
Gatekeeper
> stage yet or not.
>
> >Or maybe just change 3280 to make cert policies optional vice
mandatory, so
> >those people who need policy!=CA but aren't subject to SDN.706 can
still find
> >the information?
>
> Exactly.  So in order to be useful (and applicable) to all users,
the RFC
> could say something like:
>
>   There's an easy way and a hard way to do this.  The easy way
involves
>   CA=policy.  The certificatePolicies MUST contain a single policy
entry with
>   a policy URL or text, MUST NOT contain user notices and notice
numbers and
>   whatnot, and DEFINITELY MUST NOT involve policy constraints,
policy
>   mappings, fuzzy dice, and two-tone paint jobs.  The hard way
involves multi-
>   policy CAs and a lot of Tylenol, for which see the current text.
>
> That way the majority of users can pick the straightforward option
that does
> what they want, and everyone who wants to do it the complex way can
also do
> that.
>
> Peter.
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1ADgTeX003698; Tue, 10 Feb 2004 05:42:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1ADgT1R003697; Tue, 10 Feb 2004 05:42:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1ADgRBQ003689 for <[e-mail]>; Tue, 10 Feb 2004 05:42:27 -0800 (PST) (envelope-from [e-mail])
Received: from [64.139.6.114] (HELO NERVANA3) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.3) with SMTP id 145157482; Tue, 10 Feb 2004 05:42:43 -0800
From: "Jean Pawluk" <[e-mail]>
To: "'Lars Johansson'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Tue, 10 Feb 2004 05:41:46 -0600
Message-ID: <001301c3efca$dd6c7250$9865fea9@NERVANA3>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bravo

 Practical PKI as a goal should to be encouraged as much as possible.

 The sheer complexity and awesome flexibility of the many standards in this
area is limiting the everyday use of PKI technology in new application
areas.

Jean




-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Lars Johansson
Sent: Tuesday, February 10, 2004 3:53 AM
To: Peter Gutmann
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data
in IE, IIS, Outlook)



Dear list,

Let me add my 0.01 euros to this thread...

Several people have argued that a CA <-> Policy paradigm would
be much simpler for most PKI users (specifically outside the
government sector) to grasp and use. However I object that this
paradigm would be the most simple one. Stated formally, what I
claim is the following:

Claim: There exists a PKI paradigm that is simpler than the CA
<-> Policy paradigm. In particular the specific PKI paradigm
requires that the correspondence between CA and Policy mustn't
be 1-1 (injective).

Proof: The proof works by giving a counterexample. Consider
an "utopic" world in which all existing CA:s have agreed on a
common single Policy. Clearly this PKI paradigm would be much
simpler to grasp and use for all relying parties in all sectors!
However this implies a many-to-one mapping between CA:s and the
single policy, a mapping which is impossible to achieve with the
CA <-> Policy paradigm. QED.

Conclusion: If simplicity is a goal (and I agree that it should)
then let's focus on standardisation of practical certificate-
policies which can be shared by several different CA:s instead
of debating wheather policy-OID:s should exist or not.

That's my opinion!
_________________________________________________
Lars Johansson M.Sc.| Consultant
[e-mail] | www.omegapoint.se
phone [phone] | fax [phone]
Omegapoint AB


-------------------
>
> "Al Arsenault" <[e-mail]> writes:
>
> >Okay, then how about the Canadian Government?  See
>
>http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp
>
> The problem is that at the moment we're stuck with having to support
an
> extremely complex and awkward mechanism to accomodate a vanishingly
small
> number of users at the expense of a large majority who don't want to
know or
> care about it, being quite happy with policy=CA.  The "vanishingly
small"
> number currently stands at two, in theory there'd be at least a
third,
> Gatekeeper, but since the government department in charge of it has
had a
> spokesman announce that "I am very grateful for the fact that, at
the moment,
> none of my colleagues has come up with a good use for it. When they
do, I will
> have to do something about it" we'll call it two, and maybe even one
> eventually depending on whether the Canadian work has reached the
Gatekeeper
> stage yet or not.
>
> >Or maybe just change 3280 to make cert policies optional vice
mandatory, so
> >those people who need policy!=CA but aren't subject to SDN.706 can
still find
> >the information?
>
> Exactly.  So in order to be useful (and applicable) to all users,
the RFC
> could say something like:
>
>   There's an easy way and a hard way to do this.  The easy way
involves
>   CA=policy.  The certificatePolicies MUST contain a single policy
entry with
>   a policy URL or text, MUST NOT contain user notices and notice
numbers and
>   whatnot, and DEFINITELY MUST NOT involve policy constraints,
policy
>   mappings, fuzzy dice, and two-tone paint jobs.  The hard way
involves multi-
>   policy CAs and a lot of Tylenol, for which see the current text.
>
> That way the majority of users can pick the straightforward option
that does
> what they want, and everyone who wants to do it the complex way can
also do
> that.
>
> Peter.
>





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1A9r2Jq078719; Tue, 10 Feb 2004 01:53:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1A9r2nx078718; Tue, 10 Feb 2004 01:53:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from tessla.levonline.com (ns3.levonline.com [217.70.32.4]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1A9r08o078666 for <[e-mail]>; Tue, 10 Feb 2004 01:53:00 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [[UNIX: localhost]]) by tessla.levonline.com (8.11.6/8.11.6) id i1A9r3015008; Tue, 10 Feb 2004 10:53:03 +0100
Message-Id: <[e-mail]>
X-Originating-IP: [137.61.234.225]
Content-Type: text/plain; charset=us-ascii
From: Lars Johansson <[e-mail]>
MIME-Version: 1.0
Subject: RE: Policy User Interfaces =?us-ascii?q?=28was?= RE: Setting X.509 Policy Data in IE, IIS, =?us-ascii?q?Outlook=29?=
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
To: Peter Gutmann  <[e-mail]>
Content-Transfer-Encoding: 8bit
Date: Tue, 10 Feb 2004 10:53:03 +0100
User-Agent: IMHO/0.98.3 (Webmail for Roxen)
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear list,

Let me add my 0.01 euros to this thread...

Several people have argued that a CA <-> Policy paradigm would 
be much simpler for most PKI users (specifically outside the 
government sector) to grasp and use. However I object that this 
paradigm would be the most simple one. Stated formally, what I 
claim is the following:

Claim: There exists a PKI paradigm that is simpler than the CA 
<-> Policy paradigm. In particular the specific PKI paradigm 
requires that the correspondence between CA and Policy mustn't 
be 1-1 (injective).

Proof: The proof works by giving a counterexample. Consider 
an "utopic" world in which all existing CA:s have agreed on a 
common single Policy. Clearly this PKI paradigm would be much 
simpler to grasp and use for all relying parties in all sectors! 
However this implies a many-to-one mapping between CA:s and the 
single policy, a mapping which is impossible to achieve with the 
CA <-> Policy paradigm. QED.

Conclusion: If simplicity is a goal (and I agree that it should) 
then let's focus on standardisation of practical certificate-
policies which can be shared by several different CA:s instead 
of debating wheather policy-OID:s should exist or not. 

That's my opinion!
_________________________________________________
Lars Johansson M.Sc.| Consultant
[e-mail] | www.omegapoint.se
phone [phone] | fax [phone]
Omegapoint AB


-------------------
> 
> "Al Arsenault" <[e-mail]> writes:
> 
> >Okay, then how about the Canadian Government?  See
>
>http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp
> 
> The problem is that at the moment we're stuck with having to support
an
> extremely complex and awkward mechanism to accomodate a vanishingly
small
> number of users at the expense of a large majority who don't want to
know or
> care about it, being quite happy with policy=CA.  The "vanishingly
small"
> number currently stands at two, in theory there'd be at least a
third,
> Gatekeeper, but since the government department in charge of it has
had a
> spokesman announce that "I am very grateful for the fact that, at
the moment,
> none of my colleagues has come up with a good use for it. When they
do, I will
> have to do something about it" we'll call it two, and maybe even one
> eventually depending on whether the Canadian work has reached the
Gatekeeper
> stage yet or not.
> 
> >Or maybe just change 3280 to make cert policies optional vice
mandatory, so
> >those people who need policy!=CA but aren't subject to SDN.706 can
still find
> >the information?
> 
> Exactly.  So in order to be useful (and applicable) to all users,
the RFC
> could say something like:
> 
>   There's an easy way and a hard way to do this.  The easy way
involves
>   CA=policy.  The certificatePolicies MUST contain a single policy
entry with
>   a policy URL or text, MUST NOT contain user notices and notice
numbers and
>   whatnot, and DEFINITELY MUST NOT involve policy constraints,
policy
>   mappings, fuzzy dice, and two-tone paint jobs.  The hard way
involves multi-
>   policy CAs and a lot of Tylenol, for which see the current text.
> 
> That way the majority of users can pick the straightforward option
that does
> what they want, and everyone who wants to do it the complex way can
also do
> that.
> 
> Peter.
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1A8v8YB058545; Tue, 10 Feb 2004 00:57:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1A8v8gx058544; Tue, 10 Feb 2004 00:57:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-1-sn1.fre.skanova.net (av1-1-sn1.fre.skanova.net [81.228.11.107]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1A8v6pu058479 for <[e-mail]>; Tue, 10 Feb 2004 00:57:06 -0800 (PST) (envelope-from [e-mail])
Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id 9D61737EF3; Tue, 10 Feb 2004 09:57:18 +0100 (CET)
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id 8248837EB2; Tue, 10 Feb 2004 09:57:18 +0100 (CET)
Received: from arport (t10o913p90.telia.com [213.64.27.210]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id i1A8v6IC007451; Tue, 10 Feb 2004 09:57:06 +0100 (CET)
Message-ID: <00ad01c3efb3$12177ee0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, "Peter Gutmann" <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Tue, 10 Feb 2004 09:51:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well, to update RFC3280 to explicitly support Policy=CA is not really
my cup of tea as I believe such an effort would be hard to get support for.

Therefore I rather play with the idea of defining a septet RFC that
deals with single policy CAs but is still 100% based on RFC3280. 

To make this concept clearer I believe that the use of this profile
should be indicated by a specific CA-cert-based extension.  This
would eliminate the "guesswork" and providing a path to future
trust store administration facilities.

Such an extension could preferably also be fitted with appropriate
metadata describing various aspects of the [by definition] uniform
issuance, in effect potentially eliminating CP documents.

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Monday, February 09, 2004 12:43
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)





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

>Okay, then how about the Canadian Government?  See
>http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp

The problem is that at the moment we're stuck with having to support an
extremely complex and awkward mechanism to accomodate a vanishingly small
number of users at the expense of a large majority who don't want to know or
care about it, being quite happy with policy=CA.  The "vanishingly small"
number currently stands at two, in theory there'd be at least a third,
Gatekeeper, but since the government department in charge of it has had a
spokesman announce that "I am very grateful for the fact that, at the moment,
none of my colleagues has come up with a good use for it. When they do, I will
have to do something about it" we'll call it two, and maybe even one
eventually depending on whether the Canadian work has reached the Gatekeeper
stage yet or not.

>Or maybe just change 3280 to make cert policies optional vice mandatory, so
>those people who need policy!=CA but aren't subject to SDN.706 can still find
>the information?

Exactly.  So in order to be useful (and applicable) to all users, the RFC
could say something like:

  There's an easy way and a hard way to do this.  The easy way involves
  CA=policy.  The certificatePolicies MUST contain a single policy entry with
  a policy URL or text, MUST NOT contain user notices and notice numbers and
  whatnot, and DEFINITELY MUST NOT involve policy constraints, policy
  mappings, fuzzy dice, and two-tone paint jobs.  The hard way involves multi-
  policy CAs and a lot of Tylenol, for which see the current text.

That way the majority of users can pick the straightforward option that does
what they want without too much bother, and everyone who wants to do it the
complex way can also do that.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19KiSB4058224; Mon, 9 Feb 2004 12:44:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i19KiSsi058223; Mon, 9 Feb 2004 12:44:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19KiQn0058213 for <[e-mail]>; Mon, 9 Feb 2004 12:44:27 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id C34DA3421F; Tue, 10 Feb 2004 09:42:31 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i15EHWA24293; Fri, 6 Feb 2004 03:17:32 +1300
Date: Fri, 6 Feb 2004 03:17:32 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>Okay, then how about the Canadian Government?  See
>http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp

The problem is that at the moment we're stuck with having to support an
extremely complex and awkward mechanism to accomodate a vanishingly small
number of users at the expense of a large majority who don't want to know or
care about it, being quite happy with policy=CA.  The "vanishingly small"
number currently stands at two, in theory there'd be at least a third,
Gatekeeper, but since the government department in charge of it has had a
spokesman announce that "I am very grateful for the fact that, at the moment,
none of my colleagues has come up with a good use for it. When they do, I will
have to do something about it" we'll call it two, and maybe even one
eventually depending on whether the Canadian work has reached the Gatekeeper
stage yet or not.

>Or maybe just change 3280 to make cert policies optional vice mandatory, so
>those people who need policy!=CA but aren't subject to SDN.706 can still find
>the information?

Exactly.  So in order to be useful (and applicable) to all users, the RFC
could say something like:

  There's an easy way and a hard way to do this.  The easy way involves
  CA=policy.  The certificatePolicies MUST contain a single policy entry with
  a policy URL or text, MUST NOT contain user notices and notice numbers and
  whatnot, and DEFINITELY MUST NOT involve policy constraints, policy
  mappings, fuzzy dice, and two-tone paint jobs.  The hard way involves multi-
  policy CAs and a lot of Tylenol, for which see the current text.

That way the majority of users can pick the straightforward option that does
what they want, and everyone who wants to do it the complex way can also do
that.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19JsmJJ055481; Mon, 9 Feb 2004 11:54:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i19Jsmqq055480; Mon, 9 Feb 2004 11:54:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19Jsi5b055472 for <[e-mail]>; Mon, 9 Feb 2004 11:54:44 -0800 (PST) (envelope-from [e-mail])
Received: from VON-THINKPAD (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i19Jss9149648; Mon, 9 Feb 2004 13:54:54 -0600
X-Mailer: 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid (via feedmail 10 I); VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 9 Feb 2004 13:54:35 -0600
To: [e-mail], [e-mail]
Subject: Paper on Proxy Certificates
From: Von Welch <[e-mail]>
Reply-To: Von Welch <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some some folks in these workings groups may find of interest our
paper describing our work with X.509 Proxy Certificates (still ID but
getting ever so close to RFC). It's both a summary of the technical
specification as well as a description of our motivations and
applications of them.

  X.509 Proxy Certificates for Dynamic Delegation
  Submitted to 3rd Annual PKI R&D Workshop
  Von Welch, Ian Foster, Carl Kesselman, Olle Mulmo, Laura Pearlman,
  Steven Tuecke, Jarek Gawor, Sam Meder, Frank Siebenlist

  http://www.globus.org/Security/papers/pki04-welch-proxy-cert-draft.pdf

Von



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19EULPN030991; Mon, 9 Feb 2004 06:30:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i19EULlG030990; Mon, 9 Feb 2004 06:30:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19EUJMl030948 for <[e-mail]>; Mon, 9 Feb 2004 06:30:19 -0800 (PST) (envelope-from [e-mail])
Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) id <[e-mail]> for [e-mail]; Mon, 09 Feb 2004 14:27:06 +0000 (GMT)
Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 09 Feb 2004 14:16:30 +0000 (GMT)
Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) id <[e-mail]> for [e-mail]; Mon, 09 Feb 2004 14:16:29 +0000 (GMT)
Received: from SCHLUMBE-U23SVV.parsippany.sns.slb.com (vpnpool390.houston.sinet.slb.com [163.188.125.134]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <[e-mail]>; Mon, 09 Feb 2004 14:16:29 +0000 (GMT)
Content-return: prohibited
Date: Mon, 09 Feb 2004 09:16:25 -0500
From: "Joel S. Kazin" <[e-mail]>
Subject: Re: question on RFC 3647
In-reply-to: <[e-mail]>
X-Sender: [e-mail]
To: "Merkle, Johannes" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:40 AM 2/9/2004 +0100, Merkle, Johannes wrote:


>I have question regarding RFC 3647: What is the difference in the scope
>of sections 6.2.1 and 6.2.11? The explanation of 6.2.1 refers to the
>same controls and standards as 6.2.1 and only seems to be more detailed.
>For me 6.2.1 looks like the requirements I would include in a CP whereas
>6.2.11 looks like the description of how these requirements are actually
>met.

I concur with your interpretation.

>  However, usually there are no separate sections for a CP and a CPS,
>so my interpretation must be wrong.

The "Framework" is intended to be CP/CPS agnostic. This appears to be an 
exception.

>Can anybody help me with this issue?

I have checked what I wrote in three actual CPS that follow the RFC for 
clients; from the section titles 6.2.1 is a slightly broader requirement 
while 6.2.11 is specific to the hardware module.  Unfortunately, as none of 
these CPS have been made public I can't share the specific text with you.


>Kind regards,
>Johannes


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  [phone]
Mobile  [phone]
email    [e-mail]
www.atosorigin.com



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19CkvdR024484; Mon, 9 Feb 2004 04:46:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i19CkvfP024483; Mon, 9 Feb 2004 04:46:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19CkumC024476 for <[e-mail]>; Mon, 9 Feb 2004 04:46:56 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (15.arlington-34-35rs.va.dial-access.att.net[12.77.113.15]) by worldnet.att.net (mtiwmhc11) with SMTP id <2004020912470711100eirc2e>; Mon, 9 Feb 2004 12:47:07 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: question on RFC 3647
Date: Mon, 9 Feb 2004 07:47:02 -0500
Message-ID: <004001c3ef0a$d112d690$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Johannes:

I agree with you that they are redundant.  We missed removing 6.2.11

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Merkle, Johannes
Sent: Monday, February 09, 2004 4:41 AM
To: [e-mail]
Subject: question on RFC 3647




I have question regarding RFC 3647: What is the difference in the scope of
sections 6.2.1 and 6.2.11? The explanation of 6.2.1 refers to the same
controls and standards as 6.2.1 and only seems to be more detailed. For me
6.2.1 looks like the requirements I would include in a CP whereas 6.2.11
looks like the description of how these requirements are actually met.
However, usually there are no separate sections for a CP and a CPS, so my
interpretation must be wrong.

Can anybody help me with this issue?

Kind regards,
Johannes



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19BhIxN019451; Mon, 9 Feb 2004 03:43:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i19BhILg019450; Mon, 9 Feb 2004 03:43:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cypherpunks.to (pakastelohi.cypherpunks.to [213.130.163.34]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19Bh8Jj019419 for <[e-mail]>; Mon, 9 Feb 2004 03:43:16 -0800 (PST) (envelope-from [e-mail])
Received: by mail.cypherpunks.to (Postfix, from userid 1050) id 36E8711556; Mon,  9 Feb 2004 12:43:11 +0100 (CET)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
From: [e-mail] (Peter Gutmann)
Message-Id: <[e-mail]>
Date: Mon,  9 Feb 2004 12:43:11 +0100 (CET)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>Okay, then how about the Canadian Government?  See
>http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp

The problem is that at the moment we're stuck with having to support an
extremely complex and awkward mechanism to accomodate a vanishingly small
number of users at the expense of a large majority who don't want to know or
care about it, being quite happy with policy=CA.  The "vanishingly small"
number currently stands at two, in theory there'd be at least a third,
Gatekeeper, but since the government department in charge of it has had a
spokesman announce that "I am very grateful for the fact that, at the moment,
none of my colleagues has come up with a good use for it. When they do, I will
have to do something about it" we'll call it two, and maybe even one
eventually depending on whether the Canadian work has reached the Gatekeeper
stage yet or not.

>Or maybe just change 3280 to make cert policies optional vice mandatory, so
>those people who need policy!=CA but aren't subject to SDN.706 can still find
>the information?

Exactly.  So in order to be useful (and applicable) to all users, the RFC
could say something like:

  There's an easy way and a hard way to do this.  The easy way involves
  CA=policy.  The certificatePolicies MUST contain a single policy entry with
  a policy URL or text, MUST NOT contain user notices and notice numbers and
  whatnot, and DEFINITELY MUST NOT involve policy constraints, policy
  mappings, fuzzy dice, and two-tone paint jobs.  The hard way involves multi-
  policy CAs and a lot of Tylenol, for which see the current text.

That way the majority of users can pick the straightforward option that does
what they want without too much bother, and everyone who wants to do it the
complex way can also do that.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i199evCX096304; Mon, 9 Feb 2004 01:40:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i199evS0096303; Mon, 9 Feb 2004 01:40:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailgate.cubis.de (send.cubis.de [195.226.172.140]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i199erH5096203 for <[e-mail]>; Mon, 9 Feb 2004 01:40:56 -0800 (PST) (envelope-from [e-mail])
Received: from mailscan-1.tuev-mitte.de (mailscan-1.tuev-mitte.de [10.0.142.44] (may be forged)) by mailgate.cubis.de (Switch-2.2.9/Switch-2.2.4) with SMTP id W19934MR00001070 for <[e-mail]>; Mon, 09 Feb 2004 10:40:59 +0100
Received: From mailscan-2.tuev-mitte.de ([10.0.142.43]) by mailscan-1.tuev-mitte.de (WebShield SMTP v4.5 MR1a P0803.345); id 1076319656691; Mon, 9 Feb 2004 10:40:56 +0100
Received: From snsrv003.secumail.de ([10.36.12.43]) by mailscan-2.tuev-mitte.de (WebShield SMTP v4.5 MR1a); id 1076319656136; Mon, 9 Feb 2004 10:40:56 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: question on RFC 3647
Date: Mon, 9 Feb 2004 10:40:56 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: question on RFC 3647
Thread-Index: AcPqSgT6L1AxHajtSYinmlivhNhm4w==
From: "Merkle, Johannes" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i199evH5096295
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have question regarding RFC 3647: What is the difference in the scope
of sections 6.2.1 and 6.2.11? The explanation of 6.2.1 refers to the
same controls and standards as 6.2.1 and only seems to be more detailed.
For me 6.2.1 looks like the requirements I would include in a CP whereas
6.2.11 looks like the description of how these requirements are actually
met. However, usually there are no separate sections for a CP and a CPS,
so my interpretation must be wrong.

Can anybody help me with this issue?

Kind regards,
Johannes



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i190NGDh089453; Sun, 8 Feb 2004 16:23:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i190NGlY089452; Sun, 8 Feb 2004 16:23:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i190NFPr089445 for <[e-mail]>; Sun, 8 Feb 2004 16:23:15 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 1944 invoked by uid 0); 9 Feb 2004 00:23:25 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.132.154) by woodstock.binhost.com with SMTP; 9 Feb 2004 00:23:25 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Sun, 08 Feb 2004 18:47:11 -0500
To: "Stefan Santesson" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: UTF-8 encoding after December 31 2003
Cc: [e-mail]
In-Reply-To: <[e-mail].c orp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan:

I have just had a telephone conversation with Tim Polk.  Sorry it took so 
long for this to happen.

We both agree with the interpretation already posted in this thread by Jim 
Schaad.  That is:

    If a CA has a certificate with a non-UTF8 subject name, then the issuer 
name
    in all certificates issued by that CA must use the non-UTF8 subject name of
    the CA in the issuer field.  This means you do not need to update the CA
    certificate.  All new end-entity certificates issued by the CA must use 
UTF8
   strings in the subject field.

Russ 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16Jh9SU043241; Fri, 6 Feb 2004 11:43:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i16Jh81u043240; Fri, 6 Feb 2004 11:43:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16Jh7Kw043232 for <[e-mail]>; Fri, 6 Feb 2004 11:43:07 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]) by anchor-post-32.mail.demon.net with esmtp (Exim 3.35 #1) id 1ApBsY-000Axb-0W; Fri, 06 Feb 2004 19:43:06 +0000
Message-ID: <[e-mail]>
Date: Fri, 06 Feb 2004 19:43:30 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Wahaj <[e-mail]>
Subject: Re: What is 20 octets ?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jack Lloyd wrote:

> octet = byte. 20 octets = 20 bytes. That means (basically), that:
>  0 <= serialNumber < 2**160
>   -J
> 

Since the MSB of an ASN1 INTEGER is the sign bit and the serialNumber 
must be non-negative its actually:

0 <= serialNumber < 2^159

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16Iw0YV040117; Fri, 6 Feb 2004 10:58:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i16Iw0hE040116; Fri, 6 Feb 2004 10:58:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i16IvxvC040108 for <[e-mail]>; Fri, 6 Feb 2004 10:57:59 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 12295 invoked by uid 0); 6 Feb 2004 18:57:55 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.243.161) by woodstock.binhost.com with SMTP; 6 Feb 2004 18:57:55 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 06 Feb 2004 13:42:25 -0500
To: "Wahaj" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: What is 20 octets ?
In-Reply-To: <000d01c3ecc7$6a638560$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wahaj:

When you DER encode the serial number, the value portion MUST NOT exceed 20 
octets.

Russ


At 08:39 PM 2/6/2004 +0500, Wahaj wrote:
>Hi All,
>
>In RFC 3280 Section 4.1.2.2  Serial number, it is defined that the 
>Conformant CAs MUST NOT use serialNumber values longer than 20 octets. Can 
>any one explain what 20 octets mean ? Does it mean 20 characters long 
>Serial number in hex e.g. FFFFFFFFFFFFFFFFFFFF ? Similar is the case for 
>CRL Number.
>
>Thanks,
>Wahaj



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16H6sTC031832; Fri, 6 Feb 2004 09:06:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i16H6sbE031831; Fri, 6 Feb 2004 09:06:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imr5.us.db.com (imr5.us.db.com [160.83.65.196]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16H6qh4031825 for <[e-mail]>; Fri, 6 Feb 2004 09:06:53 -0800 (PST) (envelope-from [e-mail])
Received: from sdbo1005.db.com by imr5.us.db.com  id i16H6pEq013374; Fri, 6 Feb 2004 12:06:52 -0500 (EST)
To: [e-mail]
Cc: [e-mail]
Subject: Re: What is 20 octets ?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Fri, 6 Feb 2004 12:06:49 -0500
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(5012HF330 | August 01, 2003) at 02/06/2004 12:06:52 PM, Serialize complete at 02/06/2004 12:06:52 PM
Content-Type: multipart/alternative; boundary="=_alternative 005E01CA85256E32_="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Wahaj,

An octet is an eight-bit unit. So 20 octets is 20 eight-bit units. For 
more information about octets and ASN.1, see "A Layman's Guide ..." on 
http://www.rsasecurity.com/rsalabs/pkcs/index.html.

Frank





"Wahaj" <[e-mail]>
Sent by: [e-mail]
02/06/2004 10:39 AM

 
        To:     <[e-mail]>
        cc: 
        Subject:        What is 20 octets ?



Hi All,
 
In RFC 3280 Section 4.1.2.2  Serial number, it  is defined that the 
Conformant CAs MUST NOT use serialNumber values longer than  20 octets. 
Can any one explain what 20 octets mean ? Does it mean 20 characters  long 
Serial number in hex e.g. FFFFFFFFFFFFFFFFFFFF ? Similar is the case for 
CRL Number.
 
Thanks,
Wahaj


The following file(s) have been deleted by: Frank Balluffi on 2/6/2004 
12:00:16 PM

smime.p7s
smime.p7s



--=_alternative 005E01CA85256E32_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2><tt>Wahaj,</tt></font>
<br>
<br><font size=2><tt>An octet is an eight-bit unit. So 20 octets is 20 eight-bit units. For more information about octets and ASN.1, see &quot;A Layman's Guide ...&quot; on http://www.rsasecurity.com/rsalabs/pkcs/index.html.</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;Wahaj&quot; &lt;[e-mail]&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: [e-mail]</font>
<p><font size=1 face="sans-serif">02/06/2004 10:39 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;&lt;[e-mail]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;What is 20 octets ?</font></table>
<br>
<br>
<br>
<br><font size=2>Hi All,</font>
<br><font size=3>&nbsp;</font>
<br><font size=2>In RFC 3280 Section 4.1.2.2&nbsp; Serial number, it &nbsp;is defined that the Conformant CAs MUST NOT use serialNumber values longer than &nbsp;20 octets. Can any one explain what 20 octets mean ? Does it mean 20 characters &nbsp;long Serial number in hex e.g. FFFFFFFFFFFFFFFFFFFF ? Similar is the case for &nbsp;CRL Number.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2>Thanks,</font>
<br><font size=2>Wahaj</font>
<br>
<br>
<br><font size=2 face="sans-serif">The following file(s) have been deleted by: Frank Balluffi on 2/6/2004 12:00:16 PM</font>
<br>
<br><font size=2 face="sans-serif">smime.p7s</font>
<br><font size=2 face="sans-serif">smime.p7s</font>
<br>
<br>
<br>
--=_alternative 005E01CA85256E32_=--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16Gd6QA030180; Fri, 6 Feb 2004 08:39:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i16Gd6th030179; Fri, 6 Feb 2004 08:39:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from centaur.acm.jhu.edu ([e-mail] [128.220.223.65]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16Gd42B030165 for <[e-mail]>; Fri, 6 Feb 2004 08:39:05 -0800 (PST) (envelope-from [e-mail])
Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id 5ECC73EBCA; Fri,  6 Feb 2004 11:39:10 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by centaur.acm.jhu.edu (Postfix) with ESMTP id 5DBCD468CE; Fri,  6 Feb 2004 11:39:10 -0500 (EST)
Date: Fri, 6 Feb 2004 11:39:10 -0500 (EST)
From: Jack Lloyd <[e-mail]>
X-X-Sender: [e-mail]
To: Wahaj <[e-mail]>
Cc: [e-mail]
Subject: Re: What is 20 octets ?
In-Reply-To: <000d01c3ecc7$6a638560$[e-mail]>
Message-ID: <[e-mail]>
X-GPG-Key-ID: 4DCDF398
X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

octet = byte. 20 octets = 20 bytes. That means (basically), that:
 0 <= serialNumber < 2**160
  -J

On Fri, 6 Feb 2004, Wahaj wrote:

> Hi All,
> 
> In RFC 3280 Section 4.1.2.2 Serial number, it is defined that the
> Conformant CAs MUST NOT use serialNumber values longer than 20 octets.
> Can any one explain what 20 octets mean ? Does it mean 20 characters long
> Serial number in hex e.g. FFFFFFFFFFFFFFFFFFFF ? Similar is the case for
> CRL Number.
> 
> Thanks,
> Wahaj
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16FWu6W026569; Fri, 6 Feb 2004 07:32:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i16FWugO026568; Fri, 6 Feb 2004 07:32:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk ([203.81.192.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16FWrjK026553 for <[e-mail]>; Fri, 6 Feb 2004 07:32:54 -0800 (PST) (envelope-from [e-mail])
Received: from identrusva1 ([203.81.215.215]) by ns3.worldcall.net.pk (8.12.8+Sun/8.12.2) with SMTP id i16FRmaB024838 for <[e-mail]>; Fri, 6 Feb 2004 20:27:54 +0500 (GMT)
Message-ID: <000d01c3ecc7$6a638560$[e-mail]>
From: "Wahaj" <[e-mail]>
To: <[e-mail]>
Subject: What is 20 octets ?
Date: Fri, 6 Feb 2004 20:39:01 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0007_01C3ECF1.41105A10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C3ECF1.41105A10
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0008_01C3ECF1.41105A10"


------=_NextPart_001_0008_01C3ECF1.41105A10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,

In RFC 3280 Section 4.1.2.2  Serial number, it is defined that the =
Conformant CAs MUST NOT use serialNumber values longer than 20 octets. =
Can any one explain what 20 octets mean ? Does it mean 20 characters =
long Serial number in hex e.g. FFFFFFFFFFFFFFFFFFFF ? Similar is the =
case for CRL Number.

Thanks,
Wahaj

------=_NextPart_001_0008_01C3ECF1.41105A10
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3526.800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi All,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In RFC 3280 Section 4.1.2.2&nbsp; =
Serial number, it=20
is defined that the Conformant CAs MUST NOT use serialNumber values =
longer than=20
20 octets. Can any one explain what 20 octets mean ? Does it mean 20 =
characters=20
long Serial number in hex e.g. FFFFFFFFFFFFFFFFFFFF ? Similar is the =
case for=20
CRL Number.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Wahaj</FONT></DIV></BODY></HTML>

------=_NextPart_001_0008_01C3ECF1.41105A10--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK3TCCAzEw
ggIZoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMRkwFwYDVQQDExBBc2NlcnRpYSBSb290IENBMB4XDTAzMDMwNDA4MTI1N1oXDTEyMDczMDEw
NDIyOVowYDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAy
IENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAnRehtg8oWu+jYIkNJVR1ueHs7k8fClUiqUsrjmhuaI6SGjw0eusF
FCCnDN2URjk+Un2OFHa3fn0lRFes/rIXvV0aB8pZGp8XJLO6u3pdfKJGnVeBtgBUr/YkXT/APo+z
pp6a52+VjOEA8tcsfkco+Ml4quvZRSQ6/5hvDlEnm08CAwEAAaOBnjCBmzAOBgNVHQ8BAf8EBAMC
AQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUc/Pyi9HYduL1F1K9IjZs+KkJi3QwNQYI
KwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhl3d3cuZ2xvYmFsdHJ1c3RmaW5kZXIuY29tMB8GA1Ud
IwQYMBaAFLFTcaAo/ecMU5odaxA87sgazV7OMA0GCSqGSIb3DQEBBQUAA4IBAQAWgwuPN1Kt4P+g
mBe25iHuepjjWcslDjZaC65ZxQuGjr/Aj7eKtBwpvw+01S4r9QIKQeT0DqlcFJlf3mDa6S25ZKxR
hUM74fxSYvfT1hAFd7NMZ2BYSj5bGHX5LWFQi1REDthiggjUt5QUGj+OVDfqBakynkiYMinw+NV0
gdRzMyhE3j3nWzeXrOXOmzea3o4bsLK2yCAJ6v+VjjTs+gBlCIE2aqSdctX2JOFJLQUyWlArBqZ9
CEdVW+iYS7PYRnOddXLiX3EC/7+MlbNMZSW234XzWQxrNqF8JzUXbYHm3jDMsprDdeC8RtiYAhQa
T/Ogeq21ndR7phpmrMQqYCSBMIIDajCCAlKgAwIBAgIBATANBgkqhkiG9w0BAQUFADA7MQswCQYD
VQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwHhcN
MDMwMzA0MDgwNjEyWhcNMTMwMzA0MDgwMTI3WjA7MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNj
ZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDR+NPebia/iGElNG3QI9TlQSWE+vwhh9N1p608htxwX3HG2PREDou8hP/r3pIkkJEs
flGxt3RVXK+Ut7IyKKB17rhlUSGmrqaRL2fAxyCsCbtak6uLqh7afDYesI1ozLn4sYMFeFWGCWKk
kNBzGfDvKebjXAz9yNxhFyLGbB+ZUkEsfjQA3GJ4Dza4FAbWUH/Q9jWpd8RU9Wx9Hi+QTfXOTaaW
Tn+QMRg9QWuP6pklSsGA65j9YWoBd+ONtSEUM0aX3p/iuecSqC/IjfSxa7hWCskQR+bzqg3xMJTa
R1JpCQds6Z1OqJX5R3UEh71FaxC2TTMgGhNDhwVuoxEgSPhlAgMBAAGjeTB3MA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSxU3GgKP3nDFOaHWsQPO7IGs1ezjA1Bggr
BgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20wDQYJKoZI
hvcNAQEFBQADggEBAKRrsf6/A8LzMqEFJcKl3pq41fPXH7gDLbayGYxvRJ15LRMwxy6A8A2SrY5r
V8u8PStKcMGKj/1R4q1zY/h2TH0eIHDNzIcXiAndZFNBIRPskQ1qIKIlTtO/TYC1f+qss9r7eKcw
Yk90WhdkdZ0k/r21Z7JQMtLGvgO+2Mc4LEb4f1Li/TdB3M0dBq0nRrDX5wiM3hoRbYkWn+0rNtHl
4fVqp5M0S9BeWud/jNIiPu2OSFCdiXDgYVYP56OfVYHuUQuTGfsRP8EI3uUE5RFqIPBj+Vx/Dwzt
/LnNR2CfKv6HPS5AstKZWr04k/RKserIBmJLuxohgfnUuLWJovLFPJkwggQ2MIIDn6ADAgECAgEG
MA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEmMCQGA1UE
CxMdQ2xhc3MgMiBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxFjAUBgNVBAMTDUFzY2VydGlhIENBIDIw
HhcNMDMwMzA1MDYyNjE4WhcNMDQwMzA1MDYwOTM0WjBLMQswCQYDVQQGEwJHQjERMA8GA1UEChMI
QXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRMwEQYDVQQDEwpXYWhhaiBLaGFuMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzoHFvOQce3P9dZDCpU5wwEANcxZHT+gmeTvuG4P/SsgXM
czLAPLe/0NLDxHw46Wl02V8uCimXyupFLbrg+jpzSFJdya7jV9I5ZVFttapkCtvoSJjlLa6CoHpz
BwQFoegmw8t5LYX5Kn+4S+Tk0uD0CdXU7PR7y/cXt3IcwtBQHwIDAQABo4ICEzCCAg8wDgYDVR0P
AQH/BAQDAgP4MAwGA1UdEwEB/wQCMAAwggEDBgNVHSAEgfswgfgwgfUGCisGAQQB/EkBAgEwgeYw
geMGCCsGAQUFBwICMIHWGoHTVGhpcyBjZXJ0aWZpY2F0ZSBpcyBmb3IgdGhlIHNvbGUgdXNlIG9m
IEFzY2VydGlhLCBhbmQgaXRzIGN1c3RvbWVycy4gQXNjZXJ0aWEgYWNjZXB0cyBubyBsaWFiaWxp
dHkgZm9yIGFueSBjbGFpbSBleGNlcHQgYXMgZXhwcmVzc2x5IHByb3ZpZGVkIGluIGl0cyBDZXJ0
aWZpY2F0ZSBQb2xpY3ksIHdoaWNoIGlzIGF2YWlsYWJsZSBmcm9tIGluZm9AYXNjZXJ0aWEuY29t
LjAdBgNVHQ4EFgQUkyOZfT2YC2dfQCQmwYgoCCj0LngwTQYDVR0fBEYwRDBCoECgPoY8aHR0cDov
L3d3dy5hc2NlcnRpYS5jb20vT25saW5lQ0EvY3Jscy9Bc2NlcnRpYUNBMi9jbGFzczIuY3JsMDUG
CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZd3d3Lmdsb2JhbHRydXN0ZmluZGVyLmNvbTAiBgNV
HREEGzAZgRd3YWhhai5raGFuQGFzY2VydGlhLmNvbTAfBgNVHSMEGDAWgBRz8/KL0dh24vUXUr0i
Nmz4qQmLdDANBgkqhkiG9w0BAQUFAAOBgQBVuzxh2zNJTMqA40kC6AqtnIDrW3b5XSfmXqtCVj8P
3ecs9aoKXrUfH9nic76xOGaHs+cEklqUFPrhK1rOoBNmA54VltcDrrEpc37pQtFm64RYlGD5ClXf
BrWVz1HngqsA5kN2POp1JQWWS0VKhNxO0Ok1ZvzI907HGMGyAcU5+DGCAcgwggHEAgEBMGUwYDEL
MAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAyIENlcnRpZmlj
YXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMgIBBjAJBgUrDgMCGgUAoIG6MBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDIwNjE1MzkwMVowIwYJ
KoZIhvcNAQkEMRYEFL2ebnx1UYiWORyOc5B68gjkq5QPMFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIdMA0GCSqGSIb3DQEBAQUABIGAPZUBLiwqz9GeTlNSNLuaw5eOprKm3cgZgpav
hYN7kJ3iDuayRsIm8oIXPG3TA+29DdcPqU5fIeARHPc+eMNYVMMPBMyr6keIZ/nTU6RaBGqZsmfm
+QnflMSx/xjaZWyMVI2P6bQX/tCnRXbROnf53drnlTD3keM39acrf4huOdcAAAAAAAA=

------=_NextPart_000_0007_01C3ECF1.41105A10--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i168UUp6072700; Fri, 6 Feb 2004 00:30:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i168UU3B072699; Fri, 6 Feb 2004 00:30:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan01.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.11/8.12.8) with SMTP id i168UScA072684 for <[e-mail]>; Fri, 6 Feb 2004 00:30:28 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 3428 invoked by alias); 6 Feb 2004 08:30:33 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 3419 invoked by alias); 6 Feb 2004 08:30:32 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 6 Feb 2004 08:30:32 -0000
Received: (qmail 7594 invoked from network); 6 Feb 2004 08:30:31 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 6 Feb 2004 08:30:31 -0000
Date: Fri, 06 Feb 2004 17:31:01 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: "Peter Hesse" <[e-mail]>
Subject: Re[2]: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.07.04 [ja]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Thanks for your review.

> After review, I agree with Denis that any parts of this I-D which the
> community agrees are useful should be integrated into the existing
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt
> document.  It does not seem that the differences between the introductory
> sections of certpathbuild and this document are worth another entire
> document.  The difference between the documents seems to be solely in the
> level of detail, and I'm not convinced that more detail than what we
> provided in certpathbuild is necessary.

I agree that PKIX should discuss a minimal definition for certification
path, and should not discuss more definition such as my I-D.

> In section 6.2.3 you state that PKIs which participate in a bridge
> infrastructure should NOT use the nameConstraints extension.  I feel that
> nameConstraints are a useful if not critical capability in an infrastructure
> such as this.  With nameConstraints, a participating CA is able to prevent
> (via excluded subtrees) successful paths from being built to specific
> certification authorities.

Right. I did not express my opinion correctly.

When a PKI use a nameConstraints in a bridge infrastructure, the PKI
SHOULD consider whether trusted PKI domain over the bridge controls its
name-spaces.
Of course PKIs SHOULD consider it always.
However, in the case such as trusting via bridge, a PKI SHOULD consider it carefully.

> The concept of a unified domain model is new to me, if there is evidence
> that it is common or worthwhile to cover in the introductory sections of
> certpathbuild, we can try to arrange that.

I will add the following description.

Unified domain model is a formation for changing from subordinaion or
for unifying from multiple PKIs.

If you are interested, you can review next  edition (will update by Feb
16th) and discuss with me directly.

Anyway, I appreciate your reviews.
I will revise my I-D as individual regardless of PKIX.

Thanks,
shima
-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1683qs4063944; Fri, 6 Feb 2004 00:03:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1683q9S063943; Fri, 6 Feb 2004 00:03:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av9-2-sn1.fre.skanova.net (av9-2-sn1.fre.skanova.net [81.228.11.116]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1683pWx063871 for <[e-mail]>; Fri, 6 Feb 2004 00:03:52 -0800 (PST) (envelope-from [e-mail])
Received: by av9-2-sn1.fre.skanova.net (Postfix, from userid 502) id 90C9237E73; Fri,  6 Feb 2004 09:03:45 +0100 (CET)
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by av9-2-sn1.fre.skanova.net (Postfix) with ESMTP id 73E4137E47; Fri,  6 Feb 2004 09:03:45 +0100 (CET)
Received: from arport (t9o913p43.telia.com [213.64.27.43]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id i1683cIC021139; Fri, 6 Feb 2004 09:03:39 +0100 (CET)
Message-ID: <006301c3ec86$f166ba00$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Olle Mulmo" <[e-mail]>
References: <[e-mail]>
Subject: Re: Adding Metadata to PKI = ERROR?
Date: Fri, 6 Feb 2004 08:57:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> CA metadata can only help a [tiny] bit here.

>Chris wrote:
>I'd go one step further and suggest that the Certificate *is* meta-data.
>It is representative of the real world agreements and legal mechanisms
>that underpin the trust it represents. A policy OID is metadata. OIDs
>are metadata. They are representatives of and placeholders for something
>else.

In case you mean the CA-certificate, I'm with you.

But current CA-certificates do not contain much information,
the situation is technically similar to EDI where information
regarding message formats and functions is specified in EDI
agreements which is about the same as CP documents.

Metadata applied to PKI would be more like XML Schemas
containing machine- and human-readable properties regarding a
certain issuance and policy.  Such information could aid administration
and development, and may even be used at run-time to dig out
particular information from associated EE-certificates.

>Olle wrote:
>http://forge.gridforum.org/projects/arrg-rg

Very interesting, they also mention the lack of machine-readable
CP/CPS info!  I believe Einstein said something about good ideas
coming to many heads when the idea is mature.  Well, that does
not make me to an Einstein...

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i167CPHq046576; Thu, 5 Feb 2004 23:12:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i167CPGJ046575; Thu, 5 Feb 2004 23:12:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mulmo.net (h150n5c1o1025.bredband.skanova.com [81.224.90.150]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i167CJHq046497 for <[e-mail]>; Thu, 5 Feb 2004 23:12:20 -0800 (PST) (envelope-from [e-mail])
Received: from FIOLOLLE (fiololle.pdc.kth.se [130.237.221.143] (may be forged)) by mulmo.net (8.11.6/8.11.6) with SMTP id i167CED08126; Fri, 6 Feb 2004 08:12:15 +0100
From: "Olle Mulmo" <[e-mail]>
To: <[e-mail]>, "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>, "Richard Levitte - VMS Whacker" <[e-mail]>
Subject: RE: Adding Metadata to PKI = ERROR?
Date: Fri, 6 Feb 2004 08:12:24 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI and semi-off topic: here are some "far out" ideas on semi-automated
evaluation of CPSes and on-the-fly key installation/CA trust:

http://forge.gridforum.org/projects/arrg-rg

/Olle

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of
[e-mail]
Sent: Thursday, February 05, 2004 14:29
To: Anders Rundgren
Cc: [e-mail]; Richard Levitte - VMS Whacker
Subject: Re: Adding Metadata to PKI = ERROR?





> CA metadata can only help a [tiny] bit here.

I'd go one step further and suggest that the Certificate *is* meta-data=



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1674JKE043524; Thu, 5 Feb 2004 23:04:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i1674JZO043522; Thu, 5 Feb 2004 23:04:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan02.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1674ECw043491 for <[e-mail]>; Thu, 5 Feb 2004 23:04:15 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 9720 invoked by alias); 6 Feb 2004 07:04:17 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 9711 invoked by alias); 6 Feb 2004 07:04:17 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 6 Feb 2004 07:04:17 -0000
Received: (qmail 5959 invoked from network); 6 Feb 2004 07:04:14 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 6 Feb 2004 07:04:14 -0000
Date: Fri, 06 Feb 2004 16:04:44 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: Kiyoshi Watanabe <[e-mail]>
Subject: Re[2]: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.07.04 [ja]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Kiyoshi,

Thanks for your comments.

> trust anchor is used to describe a root CA (entity), having the
> certificate upon which a certificate user relies as being valid
> without the need for validation testing.
> 
> trust point is used to describe a certificate that may be either (a)
> the root certificate in a hierarchical PKI, (b) the certificate of the
> CA that issued the user's own certificate in a mesh PKI, or (c) any
> certificate accepted by the user in a trust-file PKI.

Your definition sounds good. :)

I used the trust point in only trust list model since I felt incongruity
with the multiple "anchor".

I think that "trust anchor" should be used widely, and "trust anchor"
and "trust point" are used differently in narrow sense if necessary.

Thanks,
shima

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15DYoIa017288; Thu, 5 Feb 2004 05:34:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i15DYobU017287; Thu, 5 Feb 2004 05:34:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15DYnkc017280 for <[e-mail]>; Thu, 5 Feb 2004 05:34:49 -0800 (PST) (envelope-from [e-mail])
Received: from ng171tdnot45.royalmail.com (unknown [144.87.146.19]) by mail4.consignia.com (Postfix) with ESMTP id 0EC7D12294B; Thu,  5 Feb 2004 13:34:58 +0000 (GMT)
Subject: Re: Adding Metadata to PKI = ERROR?
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], "Richard Levitte - VMS Whacker" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 5 Feb 2004 13:29:16 +0000
X-MIMETrack: Serialize by Router on m22ng32/H/MTANET(Release 6.5|September 26, 2003) at 05/02/2004 13:34:58
MIME-Version: 1.0
Content-type: multipart/related;  Boundary="0__=8FBBE4A2DFDA420F8f9e8a93df938690918c8FBBE4A2DFDA420F"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=8FBBE4A2DFDA420F8f9e8a93df938690918c8FBBE4A2DFDA420F
Content-type: multipart/alternative; 
	Boundary="1__=8FBBE4A2DFDA420F8f9e8a93df938690918c8FBBE4A2DFDA420F"

--1__=8FBBE4A2DFDA420F8f9e8a93df938690918c8FBBE4A2DFDA420F
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable




> CA metadata can only help a [tiny] bit here.

I'd go one step further and suggest that the Certificate *is* meta-data=
.
It is representative of the real world agreements and legal mechanisms
that underpin the trust it represents. A policy OID is metadata. OIDs
are metadata. They are representatives of and placeholders for somethin=
g
else.

Chris


     ******************************************************************=
****
     This email and any attachments are confidential and intended for t=
he
     addressee only. If you are not the named recipient, you must not u=
se,
     disclose, reproduce, copy or distribute the contents of this
     communication. If you have received this in error, please contact =
the
     sender and then delete this email from your system.
     ******************************************************************=
****

=

--1__=8FBBE4A2DFDA420F8f9e8a93df938690918c8FBBE4A2DFDA420F
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body><br>
<img src=3D"cid:10__=[e-mail]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for &quot;Anders Rundgr=
en&quot; &lt;[e-mail]&gt;">&quot;Anders Rundgren&quot;=
 &lt;[e-mail]&gt;<br>
<br>
<font face=3D"Courier New">&gt; CA metadata can only help a [tiny] bit =
here.<br>
</font><br>
<font face=3D"Courier New">I'd go one step further and suggest that the=
 Certificate *is* meta-data.</font><br>
<font face=3D"Courier New">It is representative of the real world agree=
ments and legal mechanisms</font><br>
<font face=3D"Courier New">that underpin the trust it represents. A pol=
icy OID is metadata. OIDs </font><br>
<font face=3D"Courier New">are metadata. They are representatives of an=
d placeholders for something </font><br>
<font face=3D"Courier New">else.</font><br>
<br>
<font face=3D"Courier New">Chris</font>


**********************************************************************
This email and any attachments are confidential and intended for the ad=
dressee only. If you are not the named recipient, you must not use, dis=
close, reproduce, copy or distribute the contents of this communication=
. If you have received this in error, please contact the sender and the=
n delete this email from your system.
**********************************************************************


</body></html>=


--1__=8FBBE4A2DFDA420F8f9e8a93df938690918c8FBBE4A2DFDA420F--


--0__=8FBBE4A2DFDA420F8f9e8a93df938690918c8FBBE4A2DFDA420F
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <10__=[e-mail]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4A2DFDA420F8f9e8a93df938690918c8FBBE4A2DFDA420F--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15CTOGv013923; Thu, 5 Feb 2004 04:29:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i15CTO8E013921; Thu, 5 Feb 2004 04:29:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15CTMCu013902 for <[e-mail]>; Thu, 5 Feb 2004 04:29:23 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 5 Feb 2004 13:29:28 +0100
Date: Thu, 05 Feb 2004 13:29:26 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Adding Metadata to PKI = ERROR?
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <01e001c3ebd9$6a763c30$0500a8c0@arport>
References: <006c01c3ebbb$7268d330$0500a8c0@arport> <[e-mail]> <01e001c3ebd9$6a763c30$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

I hear what you say, but I can't see the use for it, and you're not
being very specific about it (you say that you can look at them as you
would look at properties in a file system, but that's hardly something
I consider useful).

The way I see it, when you place trust in a CA, and in the set of
policies it comes with (or perhaps just s subset), what you usually do
is to store that CA cert somewhere in a database (the Windows key
store, the OpenSSL certificate directory, whatever) and decide to
trust things signed with the corrresponding private key.  Since the
path validation algorithm in RFC3280 doesn't care about policy
pointers in a self-signed CA certificate, you have to indicate with
some other means what policies you want to place trust in (unless you
go for anyPolicy), and I would attach them to that CA cert.  The
alternate thing to do is cross-certify if you have your own CA (and
you can do it one-way if you choose to), but at that point, it's your
own set of policies that are important, and not theirs any more,
except for the purpose of policy mapping.

What I see here is a crucial philosophical difference.  If you would
use the policy OIDs that come in some self-signed CA certificate, it
would mean that the CA dictates exactly what policies your accepting,
and you would have to follow suit with CA cert upgrades.  On the other
hand, if you aquire the policy OIDs by other means, you're your own
man and noone else can tell you what you trust or don't trust.  With
that in mind, policy pointers in self-signed CA certificates is just
redundant information and could be regarded as a curiosity to watch
when you feel like amusing yourself in perverse ways, or at worst a
possible source of confusion since there may be a time that they don't
match what you have in your "policy trust database" (whatever that
would be), making the administrator wonder what's what.

NOTE: This is *my* interpretation.  If there's something I've
misunderstood here, I would deeply appreciate it if someone would
correct my errors.

In message <01e001c3ebd9$6a763c30$0500a8c0@arport> on Thu, 5 Feb 2004 12:15:51 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Thanx Richard,
anders.rundgren> And I agree 100%.
anders.rundgren> 
anders.rundgren> Trust is indeed something that you establish using
anders.rundgren> various out-of-band methods.  CA metadata can only
anders.rundgren> help a [tiny] bit here.
anders.rundgren> 
anders.rundgren> I primarily regard Metadata as potentially useful in
anders.rundgren> a PKI context once trust has been established.
anders.rundgren> 
anders.rundgren> If you view properies on a CA-cert (be it self-signed
anders.rundgren> or not), augmented with metadata you could preferably
anders.rundgren> look on things associated with the issuance.  This
anders.rundgren> vould be analogous to viewing properties on a file
anders.rundgren> system folder, where you typically get an indication
anders.rundgren> of how many files there are in the folder.  That is,
anders.rundgren> metadata is an administrator thing.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15BLW3b009958; Thu, 5 Feb 2004 03:21:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i15BLWTh009957; Thu, 5 Feb 2004 03:21:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-1-sn1.fre.skanova.net (av1-1-sn1.fre.skanova.net [81.228.11.107]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15BLVUu009949 for <[e-mail]>; Thu, 5 Feb 2004 03:21:32 -0800 (PST) (envelope-from [e-mail])
Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id 5B83737EB8; Thu,  5 Feb 2004 12:21:35 +0100 (CET)
Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id 4D61737E81 for <[e-mail]>; Thu,  5 Feb 2004 12:21:35 +0100 (CET)
Received: from arport (t10o913p1.telia.com [213.64.27.121]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 4601937E5F; Thu,  5 Feb 2004 12:21:33 +0100 (CET)
Message-ID: <01e001c3ebd9$6a763c30$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>
References: <006c01c3ebbb$7268d330$0500a8c0@arport> <[e-mail]>
Subject: Re: Adding Metadata to PKI = ERROR?
Date: Thu, 5 Feb 2004 12:15:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanx Richard,
And I agree 100%.

Trust is indeed something that you establish using various out-of-band
methods.  CA metadata can only help a [tiny] bit here.

I primarily regard Metadata as potentially useful in a PKI context once
trust has been established.

If you view properies on a CA-cert (be it self-signed or not), augmented
with metadata you could preferably look on things associated with the
issuance.  This vould be analogous to viewing properties on a file system
folder, where you typically get an indication of how many files there are
in the folder.  That is, metadata is an administrator thing.

Anders

----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, February 05, 2004 10:54
Subject: Re: Adding Metadata to PKI = ERROR?


Dear Anders,

I must honestly say that I'm not entirely sure why having CP and CPS
pointers in a self-signed cert would be such a big deal.  They would
be completely ignored by the path validation as shown in RFC3280 (at
least as far as I understand the algorithm), but would be informative.

However, there's a different thing we touch here, and it's entirely
non-technical: trust.  And this is something that was learned more or
less by everyone back when PGP came to this world if not earlier.  You
simply can't (well, actually, you can if you want to, but then I'll
call you a fool) put any trust in a bunch of bits that you received
from the Gods know where, no matter what more or less fancy documents
come with it.

To get back to how things work out with PGP, you normally verify the
fingerprint of the key you received by talking to the owner of said
key and often checking that the person is really who he or she is (ID
check or something similar) before you put any trust in that key.
Trusting a CA certificate SHOULD be no different.  The work is to call
the people responsible for a CA, check the fingerprint and verify with
those people that the CA is really what it pretends to be (and if
you're paranoid, you will *maybe* decide to trust them :-)).

If the unknown CA has a cert signed by someone else that you trust,
the matter is often different, but then, you don't have the unknown CA
as a trust point anyway, do you?

If I found a self-signed CA certificate with CP and CPS pointers in
it, I would regard it as possibly useful information, but if I did the
work properly (which I'll admit I don't very often, yet :-/), I would
still have to get in touch with the responsible people, make sure they
identify themselves and the CA cert properly, and request that they
send me copies of their CP and CPS.

In message <006c01c3ebbb$7268d330$0500a8c0@arport> on Thu, 5 Feb 2004 08:41:01 +0100, "Anders Rundgren" <[e-mail]>
said:

anders.rundgren> Metadata (data about data) is an intrinsic part of
anders.rundgren> many information resources like relational databases,
anders.rundgren> file systems and various proprietary systems.  The
anders.rundgren> main utility of metadata is to support administration
anders.rundgren> and development processes.
anders.rundgren>
anders.rundgren> However, the PKI community has so far resisted (or
anders.rundgren> neglected) this possibility and mainly relies on
anders.rundgren> out-of-band distributed information like certificate
anders.rundgren> policy documents, which essentially is "manual"
anders.rundgren> metadata.
anders.rundgren>
anders.rundgren> According to some PKI people, putting something like
anders.rundgren> a subset or parameterized CP doc in a self-signed CA
anders.rundgren> certificate using an X.509.v3 non-critical extension,
anders.rundgren> violates the very core of PKI and X.509, as the CA
anders.rundgren> cannot vouch for itself.
anders.rundgren>
anders.rundgren> Isn't that what a CP doc does today but without using
anders.rundgren> cryptographic bindings?
anders.rundgren>
anders.rundgren> In my opinion such an extension is principally no
anders.rundgren> different than CAs having Subject DNs like
anders.rundgren> "CN="TrustUS High-value CA".
anders.rundgren>
anders.rundgren> Any opinions on this?

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15BD0qR008842; Thu, 5 Feb 2004 03:13:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i15BD0Ww008841; Thu, 5 Feb 2004 03:13:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15BCvFK008830 for <[e-mail]>; Thu, 5 Feb 2004 03:12:57 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 11:12:58 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Feb 2004 11:12:41 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 11:12:35 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: UTF-8 encoding after December 31 2003
Date: Thu, 5 Feb 2004 11:12:32 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: UTF-8 encoding after December 31 2003
Thread-Index: AcPp8WxIK7RFqh/jTyawxnMdWMbAggAT3bcgAGXdHOA=
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Tim Polk" <[e-mail]>, "Russ Housley" <[e-mail]>
X-OriginalArrivalTime: 05 Feb 2004 11:12:35.0803 (UTC) FILETIME=[F5561AB0:01C3EBD8]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3EBD9.10EB6987"

------_=_NextPart_001_01C3EBD9.10EB6987
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Russ, Tim,

=20

What is the chance to get an authoritative answer from the editors of
3280

=20

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

> From: Stephen Kent [mailto:[e-mail]]

> Sent: den 3 februari 2004 19:00

> To: Stefan Santesson

> Cc: [e-mail]

> Subject: UTF-8 encoding after December 31 2003

>=20

> I think the most authoritative  answer will come from the editors of
3280.

>=20

> The cited portion of 3280 re accommodating the changeover to UTF8

> encoding seems straightforward at first glance, but I agree that some

> clarification would help.

>=20

> Steve

=20

/Stefan

________________________________

From: Stefan Santesson=20
Sent: den 3 februari 2004 11:40
To: Deacon, Alex; Stefan Santesson; '[e-mail]';
'[e-mail]'; '[e-mail]'; 'Tim Polk'; 'Russ Housley'
Subject: RE: UTF-8 encoding after December 31 2003

=20

Thanks Alex,

=20

With both you and Jim making the same interpretation I start to feel
hopeful that this is the actual intent of exception B).

=20

I would appreciate though, for the record, a WG chair/editor
confirmation, but until someone comes forth and state otherwise we will
regard this as the intent of the standard.

I would also ask the editors to note for future updates to look into
eventual clarification of this text.=20

=20

/Stefan

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Deacon, Alex
Sent: den 3 februari 2004 00:36
To: Stefan Santesson; '[e-mail]'; '[e-mail]';
'[e-mail]'; 'Tim Polk'; 'Russ Housley'
Subject: RE: UTF-8 encoding after December 31 2003

=20

Stefan,

=20

Based on my reading of 3280, which seems to be in line with your
interpretation, the answer to your question would be yes.  Exception b)
states that, regardless of encoding, the contents of the issuer field in
all certs issued by a CA must match the contents in its subject field. =20

=20

Alex

=20

=20

	-----Original Message-----
	From: Stefan Santesson [mailto:[e-mail]]=20
	Sent: Friday, January 30, 2004 8:41 AM
	To: [e-mail]; [e-mail]; [e-mail]; Tim
Polk; Russ Housley
	Subject: RE: UTF-8 encoding after December 31 2003

	Due to the silence on this thread I have to restate the question
and ask for WG chairs and RFC 3280 editors' clarification:

	=20

	I'm asking for clarification on how to interpret the exceptions
to UTF-8 encoding after December 31, 2003 stated in 4.1.2.4.

	=20

	=20

	Case:

	I have a CA (root or intermediate) with an operational CA
certificate that is valid far into the future e.g. 2010. This CA
certificate has Issuer and subject name in old encoding.

	=20

	Question:=20

	Is it OK to issue certificates from that CA that has an Issuer
name matching the subject name of the existing CA certificate (in old
encoding)?

	=20

	=20

	/Stefan

=09
________________________________


	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Jim Schaad
	Sent: den 26 januari 2004 21:32
	To: Stefan Santesson; [e-mail]
	Subject: RE: UTF-8 encoding after December 31 2003

	=20

	Stefan,

	=20

	I don't read (b) in the same way as you do.  I read this as
saying if a CA has a certificate with a non-UTF8 encoded subject name,
then the issuer name in all certificates it issues MUST be the non-UTF8
subject name of the CA.  This means you don't need to update the CA
certificate, but that all new certificates issued by the CA must be
using UTF8 strings.

	=20

	jim

		-----Original Message-----
		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Monday, January 26, 2004 9:23 AM
		To: [e-mail]
		Subject: UTF-8 encoding after December 31 2003

		All,

		=20

		I have a problem with the UTF-8 requirements in RFC 3280
after December 31, and would appreciate guidance on interpretation of
RFC 3280 as well as other implementers view on this.

		=20

		The situation:

		=20

		Conforming CA:s must encode attributes of
DirectotyString types as UTF-8 after=20

		December 31, 2003.

		=20

		Exceptions are stated in RFC 3280 (section 4.1.2.4):

		=20

		   Exceptions to the December 31, 2003 UTF8 encoding
requirements are as

		   follows:

		=20

		      (a)  CAs MAY issue "name rollover" certificates to
support an

		      orderly migration to UTF8String encoding.  Such
certificates would

		      include the CA's UTF8String encoded name as issuer
and and the old

		      name encoding as subject, or vice-versa.

		=20

		      (b)  As stated in section 4.1.2.6, the subject
field MUST be

		      populated with a non-empty distinguished name
matching the

		      contents of the issuer field in all certificates
issued by the

		      subject CA regardless of encoding.

		=20

		=20

		My interpretation of this is:

		=20

		a) only applies for self issued certificates with the
same CA name as issuer and subject (but in different encodings).
Introducing such name roll-over certificates extend the certificate
chain and may be problematic since it may break both naming and path
length constraints expressed by chaining CAs.

		=20

		b) seams to be a catch 22. You can populate the subject
field with old encoding to match old encoded issuer names in descending
certificates, but since no descending CA can populate the issuer field
with old encoding it doesn't really apply.

		=20

		=20

		The issue:

		There seems to be a problem with practical reality here
in case the interpretation above is correct.

		=20

		Question 1)

		What if I have a Root CA valid to 2020 with subject and
issuer name in old encoding?

		=20

		Can that Root CA issue an intermediary CA certificate
with the issuer field in old encoding, matching the subject field of the
current root CA Certificate?

		=20

		Question 2)

		What if I have a CA with a current operating CA
certificate that expires 2006. Can this CA issue certificates after
December 31, with the issuer name in old encoding, matching the encoding
of the current CA certificate until it expires, or must this CA change
its name and have its CA certificate renewed before December 31?

		=20

		If RFC 3280 prevents operating CAs to issue certificates
with the issuer field matching the CA:s current certificate, until it
expires, then we face a huge legacy problem. Especially since name
matching for different encoding types are not required.

		=20

		4.1.2.4 states

		"(a)  attribute values encoded in different types (e.g.,

		      PrintableString and BMPString) MAY be assumed to
represent

		      different strings;"

		=20

		=20

		If my concerns are wrong and the issuing such
certificates is allowed, then this needs to be clarified.

		=20

		=20

		=20

		Stefan Santesson

		Program Manager, Windows Security

		=20


------_=_NextPart_001_01C3EBD9.10EB6987
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[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>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<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:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<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'>Russ, =
Tim,<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'>What is the chance to get an =
authoritative
answer from the editors of 3280<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=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DDA
style=3D'font-size:10.0pt'>&gt; -----Original =
Message-----<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DDA
style=3D'font-size:10.0pt'>&gt; Sent: den 3 februari 2004 =
19:00<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; To: <st1:PersonName w:st=3D"on">Stefan =
Santesson</st1:PersonName><o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Subject: UTF-8 encoding after December 31 =
2003<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; I think the most authoritative&nbsp; answer will come from =
the
editors of 3280.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; The cited portion of 3280 re accommodating the changeover =
to UTF8<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; encoding seems straightforward at first glance, but I agree =
that
some<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; clarification would help.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; Steve<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>

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

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<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'> =
<st1:PersonName
w:st=3D"on">Stefan Santesson</st1:PersonName> <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 3 februari 2004 =
11:40<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Deacon, Alex; =
<st1:PersonName
w:st=3D"on">Stefan Santesson</st1:PersonName>; '[e-mail]';
'[e-mail]'; '[e-mail]'; 'Tim Polk'; 'Russ Housley'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: UTF-8 =
encoding after
December 31 2003</span></font><o:p></o:p></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 class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks =
Alex,<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'>With both you and Jim making the =
same
interpretation I start to feel hopeful that this is the actual intent of
exception B).<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'>I would appreciate though, for the =
record,
a WG chair/editor confirmation, but until someone comes forth and state
otherwise we will regard this as the intent of the =
standard.<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'>I would also ask the editors to =
note for
future updates to look into eventual clarification of this text. =
<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>

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

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<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'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Deacon, Alex<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 3 februari 2004 =
00:36<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Stefan
 Santesson</st1:PersonName>; '<st1:PersonName =
w:st=3D"on">[e-mail]</st1:PersonName>';
'[e-mail]'; '[e-mail]'; 'Tim Polk'; 'Russ Housley'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: UTF-8 =
encoding after
December 31 2003</span></font><o:p></o:p></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>

<div>

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

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Based on my reading of 3280, which seems to =
be in
line with your interpretation, the answer to your question would be =
yes.&nbsp;
Exception b) states that, regardless of encoding, the contents of the =
issuer
field in all certs issued by a CA must match the contents in its subject
field.&nbsp; </span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Alex</span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'><o:p></o:p></span=
></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid black =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=
>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> <st1:PersonName =
w:st=3D"on">Stefan
 Santesson</st1:PersonName> [mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, January 30, =
2004
8:41 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">[e-mail]</st1:PersonName>;
[e-mail]; [e-mail]; Tim Polk; Russ Housley<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: UTF-8 =
encoding after
December 31 2003</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Due to the silence on this thread I =
have
to restate the question and ask for WG chairs and RFC 3280 editors'
clarification:<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'>I'm asking for clarification on how =
to
interpret the exceptions to UTF-8 encoding after December 31, 2003 =
stated in
4.1.2.4.<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'><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'>Case:<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'>I have a CA (root or intermediate) =
with an
operational CA certificate that is valid far into the future e.g. 2010. =
This CA
certificate has Issuer and subject name in old =
encoding.<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'>Question: =
<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'>Is it OK to issue certificates from =
that
CA that has an Issuer name matching the subject name of the existing CA
certificate (in old encoding)?<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'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<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'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Jim Schaad<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 26 januari 2004 =
21:32<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Stefan
 Santesson</st1:PersonName>; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: UTF-8 =
encoding after
December 31 2003</span></font><o:p></o:p></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>

<div>

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


</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I don't read (b) in the same way as =
you
do.&nbsp; I read this as saying if a CA has a certificate with&nbsp;a =
non-UTF8
encoded subject name, then the issuer name in all certificates it issues =
MUST
be the non-UTF8 subject name of the CA.&nbsp; This means you don't need =
to
update the CA certificate, but that all new certificates issued by the =
CA must
be using UTF8 strings.</span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

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

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 3.0pt;
margin-left:2.95pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=
>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b><st1:PersonName w:st=3D"on">Stefan =
Santesson</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, January 26, =
2004
9:23 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> UTF-8 encoding =
after
December 31 2003</span></font><o:p></o:p></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I have a problem with the UTF-8 requirements in RFC 3280 after =
December
31, and would appreciate guidance on interpretation of RFC 3280 as well =
as
other implementers view on this.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The situation:<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Conforming CA:s must encode attributes of DirectotyString types =
as
UTF-8 after <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>December 31, 2003.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Exceptions are stated in RFC 3280 (section =
4.1.2.4):<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; Exceptions to the December 31, 2003 UTF8 encoding
requirements are as<o:p></o:p></span></font></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; CAs MAY issue =
&quot;name
rollover&quot; certificates to support an<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; orderly migration to UTF8String
encoding.&nbsp; Such certificates would<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include the CA's UTF8String =
encoded name
as issuer and and the old<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;name encoding as subject, or =
vice-versa.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; As stated in section =
4.1.2.6,
the subject field MUST be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; populated with a non-empty =
distinguished
name matching the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contents of the issuer field in =
all
certificates issued by the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;subject CA regardless of =
encoding.<o:p></o:p></span></font></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>My interpretation of this is:<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>a) only applies for self issued certificates with the same CA =
name as
issuer and subject (but in different encodings). Introducing such name
roll-over certificates extend the certificate chain and may be =
problematic
since it may break both naming and path length constraints expressed by
chaining CAs.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>b) seams to be a catch 22. You can populate the subject field =
with old
encoding to match old encoded issuer names in descending certificates, =
but
since no descending CA can populate the issuer field with old encoding =
it
doesn't really apply.<o:p></o:p></span></font></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The issue:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>There seems to be a problem with practical reality here in case =
the
interpretation above is correct.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 1)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a Root CA valid to 2020 with subject and issuer =
name in
old encoding?<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Can that Root CA issue an intermediary CA certificate with the =
issuer
field in old encoding, matching the subject field of the current root CA
Certificate?<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 2)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a CA with a current operating CA certificate that
expires 2006. Can this CA issue certificates after December 31, with the =
issuer
name in old encoding, matching the encoding of the current CA =
certificate until
it expires, or must this CA change its name and have its CA certificate =
renewed
before December 31?<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If RFC 3280 prevents operating CAs to issue certificates with =
the
issuer field matching the CA:s current certificate, until it expires, =
then we
face a huge legacy problem. Especially since name matching for different
encoding types are not required.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>4.1.2.4 states<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&quot;(a)&nbsp; attribute values encoded in different types =
(e.g.,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PrintableString and BMPString) =
MAY be
assumed to represent<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different =
strings;&quot;<o:p></o:p></span></font></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If my concerns are wrong and the issuing such certificates is =
allowed,
then this needs to be clarified.<o:p></o:p></span></font></p>

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

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

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

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><strong><b><font =
size=3D2
 color=3Dolive face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
 color:olive'>Stefan =
Santesson</span></font></b></strong></st1:PersonName><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive'>Program Manager, Windows =
Security</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>

</blockquote>

</div>

</blockquote>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C3EBD9.10EB6987--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i159t8kI097775; Thu, 5 Feb 2004 01:55:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i159t8Ca097774; Thu, 5 Feb 2004 01:55:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i159t6oP097729 for <[e-mail]>; Thu, 5 Feb 2004 01:55:07 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 5 Feb 2004 10:55:06 +0100
Date: Thu, 05 Feb 2004 10:54:33 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Adding Metadata to PKI = ERROR?
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <006c01c3ebbb$7268d330$0500a8c0@arport>
References: <006c01c3ebbb$7268d330$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Anders,

I must honestly say that I'm not entirely sure why having CP and CPS
pointers in a self-signed cert would be such a big deal.  They would
be completely ignored by the path validation as shown in RFC3280 (at
least as far as I understand the algorithm), but would be informative.

However, there's a different thing we touch here, and it's entirely
non-technical: trust.  And this is something that was learned more or
less by everyone back when PGP came to this world if not earlier.  You
simply can't (well, actually, you can if you want to, but then I'll
call you a fool) put any trust in a bunch of bits that you received
from the Gods know where, no matter what more or less fancy documents
come with it.

To get back to how things work out with PGP, you normally verify the
fingerprint of the key you received by talking to the owner of said
key and often checking that the person is really who he or she is (ID
check or something similar) before you put any trust in that key.
Trusting a CA certificate SHOULD be no different.  The work is to call
the people responsible for a CA, check the fingerprint and verify with
those people that the CA is really what it pretends to be (and if
you're paranoid, you will *maybe* decide to trust them :-)).

If the unknown CA has a cert signed by someone else that you trust,
the matter is often different, but then, you don't have the unknown CA
as a trust point anyway, do you?

If I found a self-signed CA certificate with CP and CPS pointers in
it, I would regard it as possibly useful information, but if I did the
work properly (which I'll admit I don't very often, yet :-/), I would
still have to get in touch with the responsible people, make sure they
identify themselves and the CA cert properly, and request that they
send me copies of their CP and CPS.

In message <006c01c3ebbb$7268d330$0500a8c0@arport> on Thu, 5 Feb 2004 08:41:01 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Metadata (data about data) is an intrinsic part of
anders.rundgren> many information resources like relational databases,
anders.rundgren> file systems and various proprietary systems.  The
anders.rundgren> main utility of metadata is to support administration
anders.rundgren> and development processes.
anders.rundgren> 
anders.rundgren> However, the PKI community has so far resisted (or
anders.rundgren> neglected) this possibility and mainly relies on
anders.rundgren> out-of-band distributed information like certificate
anders.rundgren> policy documents, which essentially is "manual"
anders.rundgren> metadata.
anders.rundgren> 
anders.rundgren> According to some PKI people, putting something like
anders.rundgren> a subset or parameterized CP doc in a self-signed CA
anders.rundgren> certificate using an X.509.v3 non-critical extension,
anders.rundgren> violates the very core of PKI and X.509, as the CA
anders.rundgren> cannot vouch for itself.
anders.rundgren> 
anders.rundgren> Isn't that what a CP doc does today but without using
anders.rundgren> cryptographic bindings?
anders.rundgren> 
anders.rundgren> In my opinion such an extension is principally no
anders.rundgren> different than CAs having Subject DNs like
anders.rundgren> "CN="TrustUS High-value CA".
anders.rundgren> 
anders.rundgren> Any opinions on this?

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i157l7cL054845; Wed, 4 Feb 2004 23:47:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i157l76U054844; Wed, 4 Feb 2004 23:47:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av9-2-sn1.fre.skanova.net (av9-2-sn1.fre.skanova.net [81.228.11.116]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i157l6Xi054770 for <[e-mail]>; Wed, 4 Feb 2004 23:47:06 -0800 (PST) (envelope-from [e-mail])
Received: by av9-2-sn1.fre.skanova.net (Postfix, from userid 502) id 58AE737E77; Thu,  5 Feb 2004 08:47:03 +0100 (CET)
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by av9-2-sn1.fre.skanova.net (Postfix) with ESMTP id 4CD0D37E58 for <[e-mail]>; Thu,  5 Feb 2004 08:47:03 +0100 (CET)
Received: from arport (t10o913p117.telia.com [213.64.27.237]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id i157kh8a017967 for <[e-mail]>; Thu, 5 Feb 2004 08:47:02 +0100 (CET)
Message-ID: <006c01c3ebbb$7268d330$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Adding Metadata to PKI = ERROR?
Date: Thu, 5 Feb 2004 08:41:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear List,

Metadata (data about data) is an intrinsic part of many information
resources like relational databases, file systems and various
proprietary systems.  The main utility of metadata is to support
administration and development processes.

However, the PKI community has so far resisted (or neglected)
this possibility and mainly relies on out-of-band distributed
information like certificate policy documents, which essentially
is "manual" metadata.

According to some PKI people, putting something like a subset
or parameterized CP doc in a self-signed CA certificate using an
X.509.v3 non-critical extension, violates the very core of PKI and
X.509, as the CA cannot vouch for itself.

Isn't that what a CP doc does today but without using cryptographic
bindings?

In my opinion such an extension is principally no different than
CAs having Subject DNs like "CN="TrustUS High-value CA".

Any opinions on this?

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14E8MqF053423; Wed, 4 Feb 2004 06:08:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i14E8M8q053422; Wed, 4 Feb 2004 06:08:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (lx.yapay.inka.de [193.197.184.188]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14E8JAX053411 for <[e-mail]>; Wed, 4 Feb 2004 06:08:20 -0800 (PST) (envelope-from [e-mail])
Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id EBDAE818A0 for <[e-mail]>; Wed,  4 Feb 2004 07:06:18 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 04 Feb 2004 07:06:18 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al Arsenault wrote:
> 
> So - is there support (other than Anders and Peter) for changing 3280 to
> make support for Cert Policies optional instead of required?

Yes.

Ciao, Michael.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13JKje8005182; Tue, 3 Feb 2004 11:20:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13JKj69005181; Tue, 3 Feb 2004 11:20:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13JKhmm005172 for <[e-mail]>; Tue, 3 Feb 2004 11:20:44 -0800 (PST) (envelope-from [e-mail])
Received: from geminiph ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id OAA101241; Tue, 3 Feb 2004 14:20:41 -0500 (EST)
Message-Id: <[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: "'Masaki SHIMAOKA'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Date: Tue, 3 Feb 2004 14:20:41 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcPj9SmLOFJSC1xzSfCx8uiBf/ZZ8QGlCE2A
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Shima,

After review, I agree with Denis that any parts of this I-D which the
community agrees are useful should be integrated into the existing
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt
document.  It does not seem that the differences between the introductory
sections of certpathbuild and this document are worth another entire
document.  The difference between the documents seems to be solely in the
level of detail, and I'm not convinced that more detail than what we
provided in certpathbuild is necessary.

In section 6.2.3 you state that PKIs which participate in a bridge
infrastructure should NOT use the nameConstraints extension.  I feel that
nameConstraints are a useful if not critical capability in an infrastructure
such as this.  With nameConstraints, a participating CA is able to prevent
(via excluded subtrees) successful paths from being built to specific
certification authorities.

The concept of a unified domain model is new to me, if there is evidence
that it is common or worthwhile to cover in the introductory sections of
certpathbuild, we can try to arrange that.

I also agree with the comments Denis made below.

--Peter

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

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Monday, January 26, 2004 4:24 AM
To: Masaki SHIMAOKA
Cc: IETF-PKIX; [e-mail]
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability


> All,
> 
> As I presented in 57th IETF meeting, I propose to make a consensus for 
> multi-domain PKI interoperability. To consider such consensus, I was 
> writing this I-D, and I finished it.
> Please review the I-D and let me know your opinion.
> 
> You can obtain the I-D from:
> http://www.ietf.org/internet-drafts/draft-shimaoka-multidomain-pki-02.
> txt
> 
> Original presentation:
> http://www.ietf.org/proceedings/03jul/slides/pkix-9/index.html
> 
> Working Page:
> http://www.jnsa.org/mpki/#id
> 
> At 56th IETF, I discussed with Tim how to standardize this I-D. As 
> result, PKIX WG seemed difficult to holding the ID as new WG draft. So 
> I am proposing this as personal draft.

Comments on draft-shimaoka-multidomain-pki-02.txt

The document does not reflect what can be called "best current practice".

RFC 2026 states:

    The BCP subseries of the RFC series is designed to be a way to
    standardize practices and the results of community deliberations.
    A BCP document is subject to the same basic set of procedures as
    standards track documents and thus is a vehicle by which the IETF
    community can define and ratify the community's best current thinking
    on a statement of principle or on what is believed to be the best way
    to perform some operations or IETF process function.

The topic of the document is rather close to the following draft:  Internet
X.509 Public Key Infrastructure: Certification Path Building available at:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt

It seems rather difficult to have two documents on nearly the same topic.
It also seems difficult to issue this document as an Informational RFC.

RFC 2026 states:

    To ensure that the non-standards track Experimental and Informational
    designations are not misused to circumvent the Internet Standards
    Process, the IESG and the RFC Editor have agreed that the RFC Editor
    will refer to the IESG any document submitted for Experimental or
    Informational publication which, in the opinion of the RFC Editor,
    may be related to work being done, or expected to be done, within the
    IETF community.

The document contains vocabulary which is not currently used with the PKIX
WG and which could create confusion if adopted.

The notion of "PKI domain" is misleading. The PKIX WG has been using the
concept of "validation policy" to describe the rules applicable to trust a
given certificate. However, this terminology is not used in this document.

The definition of "subscriber" is misleading and should not be confused with
"subject".

It is also misleading to say "In a single-domain PKI (whatever this notion
may mean), these [i.e. trust anchors] may be omitted tacitly". There always
exists at least one trust anchor, otherwise it is impossible to verify a
certificate.

The wordings "unified domain model" and "unificate CA" are introduced but
are not explained.

The definition of PKI domain which seems to map to the concept of validation
policy is wrong: the MUST and SHOULD included in the definition are wrong. 
The notion of domain policy is inadequate as well.

The notion of Mesh PKI is introduced in the definition section, but is not
explained.

The notion of "principal CA" is not needed.

The notion of "PKI domain" of the subscriber is unclear. Does it means that
the CA that has issued the end-entity certificate musty issue a self-signed
certificate ?

What is the difference between a trust anchor and a trust point ?

The notions of "Public PKI" and "Private PKI" are not appropriate. What can
be a trust point registered without clear agreement ???

Trust relationship can't be restricted to Trust relationships between CAs. 
There are first between CAs and relying parties.

There is no reason why CAs in a trust list SHOULD NOT cross-certify each
other.

The most important case for trust list has been omitted: it is when the
trust list is establish by an authority which trusts some CAs. Then relying
parties trusting that authority can use the trust lists established by that
authority for some specific purpose.

In section 3.2 about Cross-Certification there should not be the following
requirements :

" CA that issues a cross-certificate MUST have a self-signed certificate".
" CA issued the cross-certificate also MUST have a self-signed certificate"

For the above reasons, I do not believe that this document should be
progressed any further.

Denis

> shima
> 
> 
> -----
> Masaki SHIMAOKA
> 
> SECOM Trust.net
> System Engineering Dpt.
> Tel: [phone] (ext.3605)
> Fax: [phone]
> e-mail: [e-mail]
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13I1sFK099994; Tue, 3 Feb 2004 10:01:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13I1s0l099993; Tue, 3 Feb 2004 10:01:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13I1qLN099978 for <[e-mail]>; Tue, 3 Feb 2004 10:01:52 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i13I1nM9015187; Tue, 3 Feb 2004 13:01:50 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020409bc4587d7a871@[128.89.89.75]>
Date: Tue, 3 Feb 2004 13:00:18 -0500
To: "Stefan Santesson" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: UTF-8 encoding after December 31 2003
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think the most authoritative  answer will come from the editors of 3280.

The cited portion of 3280 re accommodating the changeover to UTF8 
encoding seems straightforward at first glance, but I agree that some 
clarification would help.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13FfwSr089257; Tue, 3 Feb 2004 07:41:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13Ffwk6089256; Tue, 3 Feb 2004 07:41:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av3-1-sn1.fre.skanova.net (av3-1-sn1.fre.skanova.net [81.228.11.109]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13FfuQa089245 for <[e-mail]>; Tue, 3 Feb 2004 07:41:57 -0800 (PST) (envelope-from [e-mail])
Received: by av3-1-sn1.fre.skanova.net (Postfix, from userid 502) id C90A337E58; Tue,  3 Feb 2004 16:41:53 +0100 (CET)
Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av3-1-sn1.fre.skanova.net (Postfix) with ESMTP id BC01F37E44 for <[e-mail]>; Tue,  3 Feb 2004 16:41:53 +0100 (CET)
Received: from arport (t11o913p77.telia.com [213.64.28.77]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 438EA37E44; Tue,  3 Feb 2004 16:41:51 +0100 (CET)
Message-ID: <034a01c3ea6b$74c3dfe0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Al Arsenault" <[e-mail]>, "David P. Kemp" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Tue, 3 Feb 2004 16:36:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al,

<snip>

>note that the US and Canadian Governments do have broad
>interoperability requirements - in fact, they had to figure out how 
>to interoperate with each other.  That's one of the reasons that the
>US Government copied the "Bridge CA" idea from the automobile
>industry - it made interoperability easier, without having to rely on
>a single (third-party) CA.

Governments' position:
- LDAP directories with certificates
- Employee-level PKI for inter-org comm.
- Cross certification
- Bridge CAs
- Expensive

The private sectors' position today
- No PKI except https server support
- shared secrets, leased lines and VPNs for inter-org comm.

The private sectors' position some time in the future
- Employee certificates are hardly ever used in inter-org comm.
- Org-level (mostly) TTP-based PKI secure inter-org comm.
- Some C2G services (tax declarations) require citizen certificates

I see some problems out there.  Policies is just a minor
"wart" in that not too tasty pudding.

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13FGG0f087921; Tue, 3 Feb 2004 07:16:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13FGGae087920; Tue, 3 Feb 2004 07:16:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13FGF4n087913 for <[e-mail]>; Tue, 3 Feb 2004 07:16:15 -0800 (PST) (envelope-from [e-mail])
Received: from arsenaultd2 (col-dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i13FGBM8002702; Tue, 3 Feb 2004 10:16:12 -0500 (EST)
From: "Al Arsenault" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Tue, 3 Feb 2004 10:16:14 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <005a01c3ea29$2cc93b50$0500a8c0@arport>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

	I think that there's general agreement with your statement

> It may be beneficial to only use single policy CAs and then associate
> relying party applications with different trust stores holding
> roots to CAs
> with suitable policies.

	However, the key word there is "MAY".  Some people/organizations believe
that "policy=CA" is best for them.  Others (e.g., the Government of Canada
PKI, see my response to Peter's message) believe that "CA => 1 or more
policies" is better.  It depends on the requirements of the specific system.

	WRT your statement:

> "At least if you intend to let your PKI extend
> outside of your own premises."

	note that the US and Canadian Governments do have broad interoperability
requirements - in fact, they had to figure out how to interoperate with each
other.  That's one of the reasons that the US Government copied the "Bridge
CA" idea from the automobile industry - it made interoperability easier,
without having to rely on a single (third-party) CA.

	I'm not disputing that for your customers, and the organizations about
which you care, a single policy per CA is better.  That's fine.  But that
set of organizations does not make up the entire universe; it does not make
up the universe of those who have interoperability requirements; and it does
not make up the entire universe of those affected by the Internet/IETF.

	As I mentioned in my response to Peter G., there seems to be a thought on
your part and his to make support for certificate policies optional vice
mandatory.  If that's your proposal, fine; let's get it out there and see
who agrees with you.  But claiming that the policy structure doesn't work is
bogus; it's supported in enough environments to refute that. And given some
level of support for cert policies, I doubt you'd have any success in
throwing it out of 3280/X.509 altogether.

				Al Arsenault




> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Anders Rundgren
> Sent: Tuesday, February 03, 2004 2:42 AM
> To: David P. Kemp; [e-mail]
> Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data
> in IE, IIS, Outlook)
>
>
>
> David,
>
> I don't think that there is any disagreement whatsoever regarding the
> utility of different policies, centralized administration of trust, and
> end-user impact.
>
> What is dividing us, is "only" how we believe that 1) multiple policies
> should be applied to PKI, and 2) how these policies are supposed to be
> handled by relying party applications and system administrators.
>
> A condensed version of my point of view is as follows:
>
> It may be beneficial to only use single policy CAs and then associate
> relying party applications with different trust stores holding
> roots to CAs
> with suitable policies.  At least if you intend to let your PKI extend
> outside of your own premises.  It also means that relying party security
> administration can be performed by a single tool, in a single place which
> can contribute to improved security.  Applications do not have to know
> anything about policies and OIDs, except that they of course no matter
> what you do, typically act on certain subject attributes etc., like e-mail
> clients look for e-mail addresses, and browsers look for DNS names.
>
> In case you want more of this I'm currently writing a paper called
> "Handling Multiple Policies in Certification Authorities"
>
> regards
> Anders Rundgren
> Consultant, PKI & e-Business
>
> ----- Original Message -----
> From: "David P. Kemp" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, February 02, 2004 21:21
> Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy
> Data in IE, IIS, Outlook)
>
>
>
> One man's trash (or fuzzy decoration) is another man's treasure.
>
> Peter Hesse described quite well the idea that there are the
> rare PKI theologists who create policy mappings between domains,
> a medium number of information owners who must understand
> policies within their own domain, and a large number of
> grandmothers, joe sixpacks, and soldiers who have no need to
> know or care.
>
> When you are outfitting 4.3 million people, you don't buy them
> all $25 fuzzy dice if a plain $5 cert is good enough.  Do you
> suppose the people who make DoD policy might have some cyber
> threat information that makes them believe the extra cost is
> worth it?  Do you suppose "policy=CA" just won't cut it in
> an interoperable environment unless you force all
> of your information owners to become high priests?
>
>
>
> Peter Gutmann wrote:
>
> > "David Cross" <[e-mail]> writes:
> >
> >
> >>My grandmother just won't understand the meaning of
> "initial-policy-mapping-
> >>inhibit" no matter how much she loves me.
> >
> >
> > And therein lies the problem.  It's not just Joe Sixpack who
> can't understand
> > any of this stuff, no-one apart from PKI theologists know (or
> care) about it.
> > So the approach that a typical technical manager/administrator
> who has to work
> > with certs will take is to use "policy = CA", with the Foo policy being
> > implicitly enforced by having the cert issued by the Foo CA, and the Bar
> > policy enforced by the Bar CA.  Going beyond private CAs (whose
> policy is
> > usually an implicit "Whatever we say it is"), if you look at
> almost any public
> > CA you'll see a pile of top- or intermediate-level CA certs
> with names that
> > are some variation on "<CA-name> <policy-name> CA" (the most
> famous being the
> > "Verisign Class X Blah CA" family) - it's the old PEM idea, but
> without the
> > single root.  Policy constraints and enforcement and mappings
> and whatnot are
> > just fuzzy dice that exist so orgs like the US DoD have
> something to decorate
> > their certs with.
> >
> > Peter.
> >



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13F52Pp087318; Tue, 3 Feb 2004 07:05:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13F52ux087317; Tue, 3 Feb 2004 07:05:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13F51Rr087303 for <[e-mail]>; Tue, 3 Feb 2004 07:05:01 -0800 (PST) (envelope-from [e-mail])
Received: from arsenaultd2 (col-dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i13F4qM8001894; Tue, 3 Feb 2004 10:04:53 -0500 (EST)
From: "Al Arsenault" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Tue, 3 Feb 2004 10:04:55 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Okay, then how about the Canadian Government?  See
http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp

Some selected quotes:

"This document defines eight certificate policies for use in the Government
of Canada Public Key Infrastructure (GoC PKI), representing four different
assurance levels (Rudimentary, Basic, Medium, and High) for both Digital
Signature and Confidentiality public key certificates. "

"GoC PKI certificates contain a registered certificate policy object
identifier (OID), which may be used to decide whether or not a certificate
is trusted for a particular purpose."

"Each CA is accredited to support one or more CPs, which it proposes to
implement."

Seriously, ignoring bashing of any particular organization (US DoD, VeriSign
or Microsoft, for example), the bottom line is that different organizations
have different requirements.  Some want or need multiple-policies-per-CA,
while others don't.  Some need interoperability (like, say, the US and
Canadian Government PKIs), while others don't. That's fine - it's a big,
diverse world and we don't all have the same requirements.

The controversy seems to be that 3280 requires that CAs and RPs support the
Cert Policies extension. Okay, if somebody wants it to be optional, that
could be a change made.   However, what I've seen in this thread is that
both Microsoft and Sun support the extension already.  A lot of custom RP
apps support it as well.  And in general it's just not that big a deal for
most environments, despite the protestations of a few.

So - is there support (other than Anders and Peter) for changing 3280 to
make support for Cert Policies optional instead of required?

		Al Arsenault



And I know I shouldn't, but I can't help myself, so a few responses:


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Tuesday, February 03, 2004 12:51 AM
> To: [e-mail]; [e-mail]
> Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data
> in IE, IIS, Outlook)
>
>
>
> "David P. Kemp" <[e-mail]> writes:
>
> >When you are outfitting 4.3 million people, you don't buy them
> all $25 fuzzy
> >dice if a plain $5 cert is good enough.  Do you suppose the
> people who make
> >DoD policy might have some cyber threat information that makes
> them believe
> >the extra cost is worth it?
>
> Oops, I forgot my traditional request for people not to dig up
> the US DoD as a
> representative example, since they could also be used as an example of the
> need for X.400 and other oddities that the rest of the world has
> ignored.

As opposed to "how (insert-name-of-company-or-academic-institution-here)
does it"? Look, no organization has ever made all the right technology
choices, and the US Government does have a tendency to sometimes hang on to
bad decisions far longer than it should, but there's a lot that was done
right.


>No
> offence to people working in that environment, but it's not even remotely
> representative of real-world usage (if the US DoD did set the pace for the
> rest of the world, we'd all be driving olive-drab 4WDs with pushbutton
> ignition and no suspension).
>

Umm, two things. First, HUMVEEs aren't the only thing in the US DoD fleet;
but it's just not sexy to show a clip on TV of a Ford Taurus driving down
the street.  Second, HUMMERs are starting to sell reasonably well, just as
Jeeps always have.  They're not for everybody, but they're out there. My
point being that different people have different requirements, but it's not
a case of "those guys over there aren't in the real world".  They're in the
real world, it's just a different part of the  real world than you inhabit.

> >Do you suppose "policy=CA" just won't cut it in an interoperable
> environment
> >unless you force all of your information owners to become high priests?
>
> In that case publish all the details in SDN.706 (which means you can set
> things up exactly the way you want it), and include a note in
> bride-of-3280 to
> say that this area is subject to application-specific standardisation by
> specific industry bodies.  This saves people reading the RFC
> having to spend a
> lot of time figuring out that they should ignore that part of the
> spec because
> it doesn't apply to them.
>
> Peter.

Or maybe just change 3280 to make cert policies optional vice mandatory, so
those people who need policy!=CA but aren't subject to SDN.706 can still
find the information?




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13AffZO069653; Tue, 3 Feb 2004 02:41:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i13Aff00069652; Tue, 3 Feb 2004 02:41:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13AfcAR069643 for <[e-mail]>; Tue, 3 Feb 2004 02:41:39 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2004 10:41:30 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Feb 2004 10:40:50 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2004 10:39:54 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: UTF-8 encoding after December 31 2003
Date: Tue, 3 Feb 2004 10:40:06 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: UTF-8 encoding after December 31 2003
Thread-Index: AcPp8WxIK7RFqh/jTyawxnMdWMbAggAT3bcg
From: "Stefan Santesson" <[e-mail]>
To: "Deacon, Alex" <[e-mail]>, "Stefan Santesson" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Tim Polk" <[e-mail]>, "Russ Housley" <[e-mail]>
X-OriginalArrivalTime: 03 Feb 2004 10:39:54.0004 (UTC) FILETIME=[0F2FD540:01C3EA42]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3EA41.FD3D98A6"

------_=_NextPart_001_01C3EA41.FD3D98A6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Alex,

=20

With both you and Jim making the same interpretation I start to feel
hopeful that this is the actual intent of exception B).

=20

I would appreciate though, for the record, a WG chair/editor
confirmation, but until someone comes forth and state otherwise we will
regard this as the intent of the standard.

I would also ask the editors to note for future updates to look into
eventual clarification of this text.=20

=20

/Stefan

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Deacon, Alex
Sent: den 3 februari 2004 00:36
To: Stefan Santesson; '[e-mail]'; '[e-mail]';
'[e-mail]'; 'Tim Polk'; 'Russ Housley'
Subject: RE: UTF-8 encoding after December 31 2003

=20

Stefan,

=20

Based on my reading of 3280, which seems to be in line with your
interpretation, the answer to your question would be yes.  Exception b)
states that, regardless of encoding, the contents of the issuer field in
all certs issued by a CA must match the contents in its subject field. =20

=20

Alex

=20

=20

	-----Original Message-----
	From: Stefan Santesson [mailto:[e-mail]]=20
	Sent: Friday, January 30, 2004 8:41 AM
	To: [e-mail]; [e-mail]; [e-mail]; Tim
Polk; Russ Housley
	Subject: RE: UTF-8 encoding after December 31 2003

	Due to the silence on this thread I have to restate the question
and ask for WG chairs and RFC 3280 editors' clarification:

	=20

	I'm asking for clarification on how to interpret the exceptions
to UTF-8 encoding after December 31, 2003 stated in 4.1.2.4.

	=20

	=20

	Case:

	I have a CA (root or intermediate) with an operational CA
certificate that is valid far into the future e.g. 2010. This CA
certificate has Issuer and subject name in old encoding.

	=20

	Question:=20

	Is it OK to issue certificates from that CA that has an Issuer
name matching the subject name of the existing CA certificate (in old
encoding)?

	=20

	=20

	/Stefan

=09
________________________________


	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Jim Schaad
	Sent: den 26 januari 2004 21:32
	To: Stefan Santesson; [e-mail]
	Subject: RE: UTF-8 encoding after December 31 2003

	=20

	Stefan,

	=20

	I don't read (b) in the same way as you do.  I read this as
saying if a CA has a certificate with a non-UTF8 encoded subject name,
then the issuer name in all certificates it issues MUST be the non-UTF8
subject name of the CA.  This means you don't need to update the CA
certificate, but that all new certificates issued by the CA must be
using UTF8 strings.

	=20

	jim

		-----Original Message-----
		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Monday, January 26, 2004 9:23 AM
		To: [e-mail]
		Subject: UTF-8 encoding after December 31 2003

		All,

		=20

		I have a problem with the UTF-8 requirements in RFC 3280
after December 31, and would appreciate guidance on interpretation of
RFC 3280 as well as other implementers view on this.

		=20

		The situation:

		=20

		Conforming CA:s must encode attributes of
DirectotyString types as UTF-8 after=20

		December 31, 2003.

		=20

		Exceptions are stated in RFC 3280 (section 4.1.2.4):

		=20

		   Exceptions to the December 31, 2003 UTF8 encoding
requirements are as

		   follows:

		=20

		      (a)  CAs MAY issue "name rollover" certificates to
support an

		      orderly migration to UTF8String encoding.  Such
certificates would

		      include the CA's UTF8String encoded name as issuer
and and the old

		      name encoding as subject, or vice-versa.

		=20

		      (b)  As stated in section 4.1.2.6, the subject
field MUST be

		      populated with a non-empty distinguished name
matching the

		      contents of the issuer field in all certificates
issued by the

		      subject CA regardless of encoding.

		=20

		=20

		My interpretation of this is:

		=20

		a) only applies for self issued certificates with the
same CA name as issuer and subject (but in different encodings).
Introducing such name roll-over certificates extend the certificate
chain and may be problematic since it may break both naming and path
length constraints expressed by chaining CAs.

		=20

		b) seams to be a catch 22. You can populate the subject
field with old encoding to match old encoded issuer names in descending
certificates, but since no descending CA can populate the issuer field
with old encoding it doesn't really apply.

		=20

		=20

		The issue:

		There seems to be a problem with practical reality here
in case the interpretation above is correct.

		=20

		Question 1)

		What if I have a Root CA valid to 2020 with subject and
issuer name in old encoding?

		=20

		Can that Root CA issue an intermediary CA certificate
with the issuer field in old encoding, matching the subject field of the
current root CA Certificate?

		=20

		Question 2)

		What if I have a CA with a current operating CA
certificate that expires 2006. Can this CA issue certificates after
December 31, with the issuer name in old encoding, matching the encoding
of the current CA certificate until it expires, or must this CA change
its name and have its CA certificate renewed before December 31?

		=20

		If RFC 3280 prevents operating CAs to issue certificates
with the issuer field matching the CA:s current certificate, until it
expires, then we face a huge legacy problem. Especially since name
matching for different encoding types are not required.

		=20

		4.1.2.4 states

		"(a)  attribute values encoded in different types (e.g.,

		      PrintableString and BMPString) MAY be assumed to
represent

		      different strings;"

		=20

		=20

		If my concerns are wrong and the issuing such
certificates is allowed, then this needs to be clarified.

		=20

		=20

		=20

		Stefan Santesson

		Program Manager, Windows Security

		=20


------_=_NextPart_001_01C3EA41.FD3D98A6
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[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>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<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:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<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'>Thanks =
Alex,<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'>With both you and Jim making the =
same
interpretation I start to feel hopeful that this is the actual intent of
exception B).<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'>I would appreciate though, for the =
record,
a WG chair/editor confirmation, but until someone comes forth and state
otherwise we will regard this as the intent of the =
standard.<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'>I would also ask the editors to =
note for
future updates to look into eventual clarification of this text. =
<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>

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

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<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'> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Deacon, Alex<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 3 februari 2004 =
00:36<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Stefan
 Santesson</st1:PersonName>; '<st1:PersonName =
w:st=3D"on">[e-mail]</st1:PersonName>';
'[e-mail]'; '[e-mail]'; 'Tim Polk'; 'Russ Housley'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: UTF-8 =
encoding after
December 31 2003</span></font><o:p></o:p></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>

<div>

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

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Based on my reading of 3280, which seems to =
be in
line with your interpretation, the answer to your question would be =
yes.&nbsp;
Exception b) states that, regardless of encoding, the contents of the =
issuer
field in all certs issued by a CA must match the contents in its subject
field.&nbsp; </span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Alex</span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'><o:p></o:p></span=
></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid black =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=
>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> <st1:PersonName =
w:st=3D"on">Stefan
 Santesson</st1:PersonName> [mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, January 30, =
2004
8:41 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">[e-mail]</st1:PersonName>;
[e-mail]; [e-mail]; Tim Polk; Russ Housley<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: UTF-8 =
encoding after
December 31 2003</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Due to the silence on this thread I =
have
to restate the question and ask for WG chairs and RFC 3280 editors'
clarification:<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'>I'm asking for clarification on how =
to
interpret the exceptions to UTF-8 encoding after December 31, 2003 =
stated in
4.1.2.4.<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'><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'>Case:<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'>I have a CA (root or intermediate) =
with an
operational CA certificate that is valid far into the future e.g. 2010. =
This CA
certificate has Issuer and subject name in old =
encoding.<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'>Question: =
<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'>Is it OK to issue certificates from =
that
CA that has an Issuer name matching the subject name of the existing CA
certificate (in old encoding)?<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'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<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'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Jim Schaad<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 26 januari 2004 =
21:32<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Stefan
 Santesson</st1:PersonName>; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: UTF-8 =
encoding after
December 31 2003</span></font><o:p></o:p></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>

<div>

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


</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I don't read (b) in the same way as =
you
do.&nbsp; I read this as saying if a CA has a certificate with&nbsp;a =
non-UTF8
encoded subject name, then the issuer name in all certificates it issues =
MUST
be the non-UTF8 subject name of the CA.&nbsp; This means you don't need =
to
update the CA certificate, but that all new certificates issued by the =
CA must
be using UTF8 strings.</span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

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

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 3.0pt;
margin-left:2.95pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=
>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b><st1:PersonName w:st=3D"on">Stefan =
Santesson</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, January 26, =
2004
9:23 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> UTF-8 encoding =
after
December 31 2003</span></font><o:p></o:p></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I have a problem with the UTF-8 requirements in RFC 3280 after =
December
31, and would appreciate guidance on interpretation of RFC 3280 as well =
as
other implementers view on this.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The situation:<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Conforming CA:s must encode attributes of DirectotyString types =
as
UTF-8 after <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>December 31, 2003.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Exceptions are stated in RFC 3280 (section =
4.1.2.4):<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; Exceptions to the December 31, 2003 UTF8 encoding
requirements are as<o:p></o:p></span></font></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; CAs MAY issue =
&quot;name
rollover&quot; certificates to support an<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; orderly migration to UTF8String
encoding.&nbsp; Such certificates would<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include the CA's UTF8String =
encoded name
as issuer and and the old<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;name encoding as subject, or =
vice-versa.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; As stated in section =
4.1.2.6,
the subject field MUST be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; populated with a non-empty =
distinguished
name matching the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contents of the issuer field in =
all
certificates issued by the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;subject CA regardless of =
encoding.<o:p></o:p></span></font></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>My interpretation of this is:<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>a) only applies for self issued certificates with the same CA =
name as
issuer and subject (but in different encodings). Introducing such name
roll-over certificates extend the certificate chain and may be =
problematic
since it may break both naming and path length constraints expressed by
chaining CAs.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>b) seams to be a catch 22. You can populate the subject field =
with old
encoding to match old encoded issuer names in descending certificates, =
but
since no descending CA can populate the issuer field with old encoding =
it
doesn't really apply.<o:p></o:p></span></font></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The issue:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>There seems to be a problem with practical reality here in case =
the
interpretation above is correct.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 1)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a Root CA valid to 2020 with subject and issuer =
name in
old encoding?<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Can that Root CA issue an intermediary CA certificate with the =
issuer
field in old encoding, matching the subject field of the current root CA
Certificate?<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 2)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a CA with a current operating CA certificate that
expires 2006. Can this CA issue certificates after December 31, with the =
issuer
name in old encoding, matching the encoding of the current CA =
certificate until
it expires, or must this CA change its name and have its CA certificate =
renewed
before December 31?<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If RFC 3280 prevents operating CAs to issue certificates with =
the
issuer field matching the CA:s current certificate, until it expires, =
then we
face a huge legacy problem. Especially since name matching for different
encoding types are not required.<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>4.1.2.4 states<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&quot;(a)&nbsp; attribute values encoded in different types =
(e.g.,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PrintableString and BMPString) =
MAY be
assumed to represent<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different =
strings;&quot;<o:p></o:p></span></font></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If my concerns are wrong and the issuing such certificates is =
allowed,
then this needs to be clarified.<o:p></o:p></span></font></p>

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

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

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

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><strong><b><font =
size=3D2
 color=3Dolive face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
 color:olive'>Stefan =
Santesson</span></font></b></strong></st1:PersonName><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive'>Program Manager, Windows =
Security</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>

</blockquote>

</div>

</blockquote>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C3EA41.FD3D98A6--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i137lY5k013473; Mon, 2 Feb 2004 23:47:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i137lY3g013472; Mon, 2 Feb 2004 23:47:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-2-sn1.fre.skanova.net (av1-2-sn1.fre.skanova.net [81.228.11.108]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i137lXlF013408 for <[e-mail]>; Mon, 2 Feb 2004 23:47:34 -0800 (PST) (envelope-from [e-mail])
Received: by av1-2-sn1.fre.skanova.net (Postfix, from userid 502) id 4BEC037E9D; Tue,  3 Feb 2004 08:47:27 +0100 (CET)
Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av1-2-sn1.fre.skanova.net (Postfix) with ESMTP id E746437E98 for <[e-mail]>; Tue,  3 Feb 2004 08:47:26 +0100 (CET)
Received: from arport (t7o913p15.telia.com [213.64.26.15]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 7CCAC37E43; Tue,  3 Feb 2004 08:47:21 +0100 (CET)
Message-ID: <005a01c3ea29$2cc93b50$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Tue, 3 Feb 2004 08:41:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

I don't think that there is any disagreement whatsoever regarding the
utility of different policies, centralized administration of trust, and
end-user impact.

What is dividing us, is "only" how we believe that 1) multiple policies
should be applied to PKI, and 2) how these policies are supposed to be
handled by relying party applications and system administrators.

A condensed version of my point of view is as follows:

It may be beneficial to only use single policy CAs and then associate
relying party applications with different trust stores holding roots to CAs
with suitable policies.  At least if you intend to let your PKI extend
outside of your own premises.  It also means that relying party security
administration can be performed by a single tool, in a single place which
can contribute to improved security.  Applications do not have to know
anything about policies and OIDs, except that they of course no matter
what you do, typically act on certain subject attributes etc., like e-mail
clients look for e-mail addresses, and browsers look for DNS names.

In case you want more of this I'm currently writing a paper called
"Handling Multiple Policies in Certification Authorities"

regards
Anders Rundgren
Consultant, PKI & e-Business

----- Original Message ----- 
From: "David P. Kemp" <[e-mail]>
To: <[e-mail]>
Sent: Monday, February 02, 2004 21:21
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)



One man's trash (or fuzzy decoration) is another man's treasure.

Peter Hesse described quite well the idea that there are the
rare PKI theologists who create policy mappings between domains,
a medium number of information owners who must understand
policies within their own domain, and a large number of
grandmothers, joe sixpacks, and soldiers who have no need to
know or care.

When you are outfitting 4.3 million people, you don't buy them
all $25 fuzzy dice if a plain $5 cert is good enough.  Do you
suppose the people who make DoD policy might have some cyber
threat information that makes them believe the extra cost is
worth it?  Do you suppose "policy=CA" just won't cut it in
an interoperable environment unless you force all
of your information owners to become high priests?



Peter Gutmann wrote:

> "David Cross" <[e-mail]> writes:
> 
> 
>>My grandmother just won't understand the meaning of "initial-policy-mapping-
>>inhibit" no matter how much she loves me.
> 
> 
> And therein lies the problem.  It's not just Joe Sixpack who can't understand
> any of this stuff, no-one apart from PKI theologists know (or care) about it.
> So the approach that a typical technical manager/administrator who has to work
> with certs will take is to use "policy = CA", with the Foo policy being
> implicitly enforced by having the cert issued by the Foo CA, and the Bar
> policy enforced by the Bar CA.  Going beyond private CAs (whose policy is
> usually an implicit "Whatever we say it is"), if you look at almost any public
> CA you'll see a pile of top- or intermediate-level CA certs with names that
> are some variation on "<CA-name> <policy-name> CA" (the most famous being the
> "Verisign Class X Blah CA" family) - it's the old PEM idea, but without the
> single root.  Policy constraints and enforcement and mappings and whatnot are
> just fuzzy dice that exist so orgs like the US DoD have something to decorate
> their certs with.
> 
> Peter.
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i135rMB2073890; Mon, 2 Feb 2004 21:53:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i135rMMa073889; Mon, 2 Feb 2004 21:53:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i135rJcE073879 for <[e-mail]>; Mon, 2 Feb 2004 21:53:20 -0800 (PST) (envelope-from [e-mail])
Received: from mc2.mcg.hitachi.co.jp by mail4.hitachi.co.jp (8.9.3p3/3.7W-mail4) id OAA21094; Tue, 3 Feb 2004 14:53:18 +0900 (JST)
Received: (from root@localhost) by mc2.mcg.hitachi.co.jp (8.11.6+Sun/8.11.6) id i135rIN12093 for <[e-mail]>; Tue, 3 Feb 2004 14:53:18 +0900 (JST)
Received: from unknown [192.168.2.1] by mc2.mcg.hitachi.co.jp with SMTP id QAA12092 ; Tue, 3 Feb 2004 14:53:18 +0900
Received: from navsg4.hitachi.co.jp by navsg4.hitachi.co.jp (8.9.3/3.7W-navsg4) id OAA27234; Tue, 3 Feb 2004 14:53:16 +0900 (JST)
Received: from mlsv4.itg.hitachi.co.jp ([158.213.165.103]) by navsg4.hitachi.co.jp (NAVGW 2.5.2.17) with SMTP id M2004020314531506033 for <[e-mail]>; Tue, 03 Feb 2004 14:53:15 +0900
Received: from mfilter-s2.itg.hitachi.co.jp by mlsv4.itg.hitachi.co.jp (8.12.10/8.12.10) id i135rFKa015047; Tue, 3 Feb 2004 14:53:15 +0900
Received: from navgw14.itg.hitachi.co.jp (unverified) by  mfilter-s2.itg.hitachi.co.jp (Content Technologies SMTPRS 4.3.10) with  SMTP id <[e-mail]>; Tue, 3 Feb  2004 14:53:15 +0900
Received: from gmml11.itg.hitachi.co.jp ([158.213.165.41]) by  navgw14.itg.hitachi.co.jp (SAVSMTP 3.1.3.37) with SMTP id  M2004020314531521050; Tue, 03 Feb 2004 14:53:15 +0900
Received: from localhost by gmml11.itg.hitachi.co.jp (AIX5.1/8.11.6p2/8.11.0)  id i135rE1230930; Tue, 3 Feb 2004 14:53:14 +0900
Date: Tue, 03 Feb 2004 14:52:25 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability
From: Kiyoshi Watanabe <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <[e-mail]>
X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Shimaoka-san,

I felt that this document could be useful as business use
case. However,
 
> > What is the difference between a trust anchor and a trust point ?

I had the above same questions on the terminology. When I read your
document, you probably use:

trust anchor is used to describe a root CA (entity), having the
certificate upon which a certificate user relies as being valid
without the need for validation testing.

trust point is used to describe a certificate that may be either (a)
the root certificate in a hierarchical PKI, (b) the certificate of the
CA that issued the user's own certificate in a mesh PKI, or (c) any
certificate accepted by the user in a trust-file PKI.

My guess is that when you describe the CA-CA relationship, you use the
trust anchor as CA entity, and when you describe the validation, you
use the trust point as the starting point of certificate validation?

With Best Regards,

-Kiyoshi
Kiyoshi Watanabe
Hitachi, Lt.d




	  



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i135pYjd073785; Mon, 2 Feb 2004 21:51:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i135pYhx073784; Mon, 2 Feb 2004 21:51:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i135pSNB073774 for <[e-mail]>; Mon, 2 Feb 2004 21:51:33 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 6B4A3340E0; Tue,  3 Feb 2004 18:50:21 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i135pMa04804; Tue, 3 Feb 2004 18:51:22 +1300
Date: Tue, 3 Feb 2004 18:51:22 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"David P. Kemp" <[e-mail]> writes:

>When you are outfitting 4.3 million people, you don't buy them all $25 fuzzy
>dice if a plain $5 cert is good enough.  Do you suppose the people who make
>DoD policy might have some cyber threat information that makes them believe
>the extra cost is worth it?

Oops, I forgot my traditional request for people not to dig up the US DoD as a
representative example, since they could also be used as an example of the
need for X.400 and other oddities that the rest of the world has ignored.  No
offence to people working in that environment, but it's not even remotely
representative of real-world usage (if the US DoD did set the pace for the
rest of the world, we'd all be driving olive-drab 4WDs with pushbutton
ignition and no suspension).

>Do you suppose "policy=CA" just won't cut it in an interoperable environment
>unless you force all of your information owners to become high priests?

In that case publish all the details in SDN.706 (which means you can set
things up exactly the way you want it), and include a note in bride-of-3280 to
say that this area is subject to application-specific standardisation by
specific industry bodies.  This saves people reading the RFC having to spend a
lot of time figuring out that they should ignore that part of the spec because
it doesn't apply to them.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12NaLBA050744; Mon, 2 Feb 2004 15:36:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12NaLjC050743; Mon, 2 Feb 2004 15:36:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12NaLVF050737 for <[e-mail]>; Mon, 2 Feb 2004 15:36:21 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.10/) with ESMTP id i12NZxcx008783; Mon, 2 Feb 2004 15:35:59 -0800 (PST)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <11CSGCJ6>; Mon, 2 Feb 2004 15:35:59 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Tim Polk'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Subject: RE: UTF-8 encoding after December 31 2003
Date: Mon, 2 Feb 2004 15:35:58 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E9E5.4F93BA50"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C3E9E5.4F93BA50
Content-Type: text/plain

Stefan,
 
Based on my reading of 3280, which seems to be in line with your
interpretation, the answer to your question would be yes.  Exception b)
states that, regardless of encoding, the contents of the issuer field in all
certs issued by a CA must match the contents in its subject field.  
 
Alex
 
 

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Friday, January 30, 2004 8:41 AM
To: [e-mail]; [e-mail]; [e-mail]; Tim Polk; Russ
Housley
Subject: RE: UTF-8 encoding after December 31 2003



Due to the silence on this thread I have to restate the question and ask for
WG chairs and RFC 3280 editors' clarification:

 

I'm asking for clarification on how to interpret the exceptions to UTF-8
encoding after December 31, 2003 stated in 4.1.2.4.

 

 

Case:

I have a CA (root or intermediate) with an operational CA certificate that
is valid far into the future e.g. 2010. This CA certificate has Issuer and
subject name in old encoding.

 

Question: 

Is it OK to issue certificates from that CA that has an Issuer name matching
the subject name of the existing CA certificate (in old encoding)?

 

 

/Stefan


  _____  


From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jim Schaad
Sent: den 26 januari 2004 21:32
To: Stefan Santesson; [e-mail]
Subject: RE: UTF-8 encoding after December 31 2003

 

Stefan,

 

I don't read (b) in the same way as you do.  I read this as saying if a CA
has a certificate with a non-UTF8 encoded subject name, then the issuer name
in all certificates it issues MUST be the non-UTF8 subject name of the CA.
This means you don't need to update the CA certificate, but that all new
certificates issued by the CA must be using UTF8 strings.

 

jim

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Monday, January 26, 2004 9:23 AM
To: [e-mail]
Subject: UTF-8 encoding after December 31 2003

All,

 

I have a problem with the UTF-8 requirements in RFC 3280 after December 31,
and would appreciate guidance on interpretation of RFC 3280 as well as other
implementers view on this.

 

The situation:

 

Conforming CA:s must encode attributes of DirectotyString types as UTF-8
after 

December 31, 2003.

 

Exceptions are stated in RFC 3280 (section 4.1.2.4):

 

   Exceptions to the December 31, 2003 UTF8 encoding requirements are as

   follows:

 

      (a)  CAs MAY issue "name rollover" certificates to support an

      orderly migration to UTF8String encoding.  Such certificates would

      include the CA's UTF8String encoded name as issuer and and the old

      name encoding as subject, or vice-versa.

 

      (b)  As stated in section 4.1.2.6, the subject field MUST be

      populated with a non-empty distinguished name matching the

      contents of the issuer field in all certificates issued by the

      subject CA regardless of encoding.

 

 

My interpretation of this is:

 

a) only applies for self issued certificates with the same CA name as issuer
and subject (but in different encodings). Introducing such name roll-over
certificates extend the certificate chain and may be problematic since it
may break both naming and path length constraints expressed by chaining CAs.

 

b) seams to be a catch 22. You can populate the subject field with old
encoding to match old encoded issuer names in descending certificates, but
since no descending CA can populate the issuer field with old encoding it
doesn't really apply.

 

 

The issue:

There seems to be a problem with practical reality here in case the
interpretation above is correct.

 

Question 1)

What if I have a Root CA valid to 2020 with subject and issuer name in old
encoding?

 

Can that Root CA issue an intermediary CA certificate with the issuer field
in old encoding, matching the subject field of the current root CA
Certificate?

 

Question 2)

What if I have a CA with a current operating CA certificate that expires
2006. Can this CA issue certificates after December 31, with the issuer name
in old encoding, matching the encoding of the current CA certificate until
it expires, or must this CA change its name and have its CA certificate
renewed before December 31?

 

If RFC 3280 prevents operating CAs to issue certificates with the issuer
field matching the CA:s current certificate, until it expires, then we face
a huge legacy problem. Especially since name matching for different encoding
types are not required.

 

4.1.2.4 states

"(a)  attribute values encoded in different types (e.g.,

      PrintableString and BMPString) MAY be assumed to represent

      different strings;"

 

 

If my concerns are wrong and the issuing such certificates is allowed, then
this needs to be clarified.

 

 

 

Stefan Santesson

Program Manager, Windows Security

 


------_=_NextPart_001_01C3E9E5.4F93BA50
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1141" name=GENERATOR><!--[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]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt 70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"
}
LI.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"
}
DIV.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV><SPAN class=146512923-02022004><FONT face="Courier New" 
size=2>Stefan,</FONT></SPAN></DIV>
<DIV><SPAN class=146512923-02022004><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=146512923-02022004><FONT face="Courier New"><FONT size=2>Based 
on my reading of 3280, which seems to be in line with your interpretation, the 
answer to your question would be yes.&nbsp; Exception b) states that, regardless 
of encoding, the contents of the issuer field in all certs issued by a CA must 
match the contents in its subject field.&nbsp; </FONT></FONT></SPAN></DIV>
<DIV><SPAN class=146512923-02022004><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=146512923-02022004><FONT face="Courier New" 
size=2>Alex</FONT></SPAN></DIV>
<DIV><SPAN class=146512923-02022004><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=146512923-02022004><FONT face="Courier New" size=2><FONT 
color=#0000ff><FONT 
face=Arial><o:p></o:p></FONT></FONT></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Stefan Santesson 
  [mailto:[e-mail]] <BR><B>Sent:</B> Friday, January 30, 2004 8:41 
  AM<BR><B>To:</B> [e-mail]; [e-mail]; [e-mail]; Tim Polk; 
  Russ Housley<BR><B>Subject:</B> RE: UTF-8 encoding after December 31 
  2003<BR><BR></FONT></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Due to the silence on 
  this thread I have to restate the question and ask for WG chairs and RFC 3280 
  editors' clarification:<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I'm asking for 
  clarification on how to interpret the exceptions to UTF-8 encoding after 
  December 31, 2003 stated in 4.1.2.4.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Case:<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I have a CA (root or 
  intermediate) with an operational CA certificate that is valid far into the 
  future e.g. 2010. This CA certificate has Issuer and subject name in old 
  encoding.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Question: 
  <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Is it OK to issue 
  certificates from that CA that has an Issuer name matching the subject name of 
  the existing CA certificate (in old encoding)?<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=MsoNormal><STRONG><B><FONT face=Arial color=olive size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: olive; FONT-FAMILY: Arial">/Stefan</SPAN></FONT></B></STRONG><o:p></o:p></P></DIV>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
  face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
  <HR tabIndex=-1 align=center width="100%" SIZE=2>
  </SPAN></FONT></DIV>
  <P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
  face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> 
  [e-mail] [mailto:[e-mail]] <B><SPAN 
  style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Jim Schaad<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Sent:</SPAN></B> den 26 januari 2004 
  21:32<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Stefan Santesson; 
  [e-mail]<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> 
  RE: UTF-8 encoding after December 31 2003</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Stefan,</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I don't read (b) in 
  the same way as you do.&nbsp; I read this as saying if a CA has a certificate 
  with&nbsp;a non-UTF8 encoded subject name, then the issuer name in all 
  certificates it issues MUST be the non-UTF8 subject name of the CA.&nbsp; This 
  means you don't need to update the CA certificate, but that all new 
  certificates issued by the CA must be using UTF8 
  strings.</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face=Arial color=blue size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">jim</SPAN></FONT><o:p></o:p></P></DIV>
  <BLOCKQUOTE 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 3pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt 2.95pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
    <P class=MsoNormal style="MARGIN-BOTTOM: 12pt"><FONT face=Tahoma 
    size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original 
    Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> 
    [e-mail] [mailto:[e-mail]] <B><SPAN 
    style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Stefan 
    Santesson<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, 
    January 26, 2004 9:23 AM<BR><B><SPAN 
    style="FONT-WEIGHT: bold">To:</SPAN></B> [e-mail]<BR><B><SPAN 
    style="FONT-WEIGHT: bold">Subject:</SPAN></B> UTF-8 encoding after December 
    31 2003</SPAN></FONT><o:p></o:p></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">All,<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">I have a problem with the UTF-8 requirements in RFC 
    3280 after December 31, and would appreciate guidance on interpretation of 
    RFC 3280 as well as other implementers view on 
    this.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">The situation:<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">Conforming CA:s must encode attributes of 
    DirectotyString types as UTF-8 after <o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">December 31, 2003.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">Exceptions are stated in RFC 3280 (section 
    4.1.2.4):<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp; Exceptions to the December 31, 2003 
    UTF8 encoding requirements are as<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp; follows:<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; CAs MAY 
    issue "name rollover" certificates to support 
an<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; orderly migration to 
    UTF8String encoding.&nbsp; Such certificates 
    would<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include the CA's 
    UTF8String encoded name as issuer and and the 
    old<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;name encoding as 
    subject, or vice-versa.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; As stated 
    in section 4.1.2.6, the subject field MUST be<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; populated with a 
    non-empty distinguished name matching the<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contents of the 
    issuer field in all certificates issued by the<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;subject CA regardless 
    of encoding.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">My interpretation of this 
    is:<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">a) only applies for self issued certificates with 
    the same CA name as issuer and subject (but in different encodings). 
    Introducing such name roll-over certificates extend the certificate chain 
    and may be problematic since it may break both naming and path length 
    constraints expressed by chaining CAs.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">b) seams to be a catch 22. You can populate the 
    subject field with old encoding to match old encoded issuer names in 
    descending certificates, but since no descending CA can populate the issuer 
    field with old encoding it doesn't really 
apply.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">The issue:<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">There seems to be a problem with practical reality 
    here in case the interpretation above is 
    correct.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">Question 1)<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">What if I have a Root CA valid to 2020 with subject 
    and issuer name in old encoding?<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">Can that Root CA issue an intermediary CA 
    certificate with the issuer field in old encoding, matching the subject 
    field of the current root CA Certificate?<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">Question 2)<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">What if I have a CA with a current operating CA 
    certificate that expires 2006. Can this CA issue certificates after December 
    31, with the issuer name in old encoding, matching the encoding of the 
    current CA certificate until it expires, or must this CA change its name and 
    have its CA certificate renewed before December 
    31?<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">If RFC 3280 prevents operating CAs to issue 
    certificates with the issuer field matching the CA:s current certificate, 
    until it expires, then we face a huge legacy problem. Especially since name 
    matching for different encoding types are not 
    required.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">4.1.2.4 states<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">"(a)&nbsp; attribute values encoded in different 
    types (e.g.,<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PrintableString and 
    BMPString) MAY be assumed to represent<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different 
    strings;"<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt">If my concerns are wrong and the issuing such 
    certificates is allowed, then this needs to be 
    clarified.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoPlainText><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial size=2><SPAN 
    style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><STRONG><B><FONT face=Arial color=olive size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: olive; FONT-FAMILY: Arial">Stefan 
    Santesson</SPAN></FONT></B></STRONG><o:p></o:p></P>
    <P class=MsoNormal><FONT face=Arial color=olive size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: olive; FONT-FAMILY: Arial">Program Manager, 
    Windows Security</SPAN></FONT><o:p></o:p></P>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></BLOCKQUOTE></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3E9E5.4F93BA50--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12KLj71039055; Mon, 2 Feb 2004 12:21:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12KLjJK039054; Mon, 2 Feb 2004 12:21:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12KLivK039045 for <[e-mail]>; Mon, 2 Feb 2004 12:21:44 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 02 Feb 2004 15:21:39 -0500
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

One man's trash (or fuzzy decoration) is another man's treasure.

Peter Hesse described quite well the idea that there are the
rare PKI theologists who create policy mappings between domains,
a medium number of information owners who must understand
policies within their own domain, and a large number of
grandmothers, joe sixpacks, and soldiers who have no need to
know or care.

When you are outfitting 4.3 million people, you don't buy them
all $25 fuzzy dice if a plain $5 cert is good enough.  Do you
suppose the people who make DoD policy might have some cyber
threat information that makes them believe the extra cost is
worth it?  Do you suppose "policy=CA" just won't cut it in
an interoperable environment unless you force all
of your information owners to become high priests?



Peter Gutmann wrote:

> "David Cross" <[e-mail]> writes:
> 
> 
>>My grandmother just won't understand the meaning of "initial-policy-mapping-
>>inhibit" no matter how much she loves me.
> 
> 
> And therein lies the problem.  It's not just Joe Sixpack who can't understand
> any of this stuff, no-one apart from PKI theologists know (or care) about it.
> So the approach that a typical technical manager/administrator who has to work
> with certs will take is to use "policy = CA", with the Foo policy being
> implicitly enforced by having the cert issued by the Foo CA, and the Bar
> policy enforced by the Bar CA.  Going beyond private CAs (whose policy is
> usually an implicit "Whatever we say it is"), if you look at almost any public
> CA you'll see a pile of top- or intermediate-level CA certs with names that
> are some variation on "<CA-name> <policy-name> CA" (the most famous being the
> "Verisign Class X Blah CA" family) - it's the old PEM idea, but without the
> single root.  Policy constraints and enforcement and mappings and whatnot are
> just fuzzy dice that exist so orgs like the US DoD have something to decorate
> their certs with.
> 
> Peter.
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12INN60030227; Mon, 2 Feb 2004 10:23:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12INNXS030226; Mon, 2 Feb 2004 10:23:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12INMEG030215 for <[e-mail]>; Mon, 2 Feb 2004 10:23:22 -0800 (PST) (envelope-from [e-mail])
Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i12ING414479; Mon, 2 Feb 2004 13:23:16 -0500 (EST)
Received: from wbl6yd026 (wbl6yd026.us.nortel.com [47.17.247.26]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i12INEM25175; Mon, 2 Feb 2004 13:23:14 -0500 (EST)
Subject: Re: Question on OCSP response....
From: "Kwok Lee" <[e-mail]>
To: Dr Stephen Henson <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="=-qImNrHit6eSqeEgrhjsP"
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Mon, 02 Feb 2004 13:23:14 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=-qImNrHit6eSqeEgrhjsP
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

I got it now. Thanks for the helps from everyone.


On Mon, 2004-02-02 at 13:02, Dr Stephen Henson wrote:

> Kwok Lee wrote:
> 
> > Hi all,
> > 
> > I am not sure it is the place for this question. If not, hopefully, 
> > someone can direct me to the right place.
> > Anyway, I am currently implementing a OCSP client, and I am using the 
> > openvalidation.org's public ocsp responder (ocsp.openvalidation.org) to 
> > verify my implementation. I am having a problem on the OCSP response I 
> > get from the responder. When I use dumpasn1 to decode the 
> > BasicOCSPResponse, it seems to me that the ResponseData is more like the 
> > following...
> > 
> > ResponseData ::= SEQUENCE {   
> > responderID          [1] EXPLICIT ResponderID,  
> > producedAt               GeneralizedTime,  
> > responses                SEQUENCE OF SingleResponse,  
> > responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
> > 
> > instead of the one defined in the RFC 2560.
> > 
> > ResponseData ::= SEQUENCE {   
> > version              [0] EXPLICIT Version DEFAULT v1,  
> > responderID              ResponderID,  
> > producedAt               GeneralizedTime,  
> > responses                SEQUENCE OF SingleResponse,  
> > responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
> > 
> > Did I miss something here ? Would someone mind to clarify that for me ?
> > 
> 
> It could be OK based on DER.
> 
> The version field will normally be the DEFAULT value (v1) and it will 
> thus be omitted.
> 
> The ResponderID is a CHOICE type:
> 
>     ResponderID ::= CHOICE {
>        byName               [1] Name,
>        byKey                [2] KeyHash }
> 
> If the Name option is present then there will be [1] EXPLICIT preceding 
> the Name structure (the default module tagging is EXPLICIT).
> 
> Steve.

--=-qImNrHit6eSqeEgrhjsP
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
</HEAD>
<BODY>
I got it now. Thanks for the helps from everyone.<BR>
<BR>
<BR>
On Mon, 2004-02-02 at 13:02, Dr Stephen Henson wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>Kwok Lee wrote:

&gt; Hi all,
&gt; 
&gt; I am not sure it is the place for this question. If not, hopefully, 
&gt; someone can direct me to the right place.
&gt; Anyway, I am currently implementing a OCSP client, and I am using the 
&gt; openvalidation.org's public ocsp responder (ocsp.openvalidation.org) to 
&gt; verify my implementation. I am having a problem on the OCSP response I 
&gt; get from the responder. When I use dumpasn1 to decode the 
&gt; BasicOCSPResponse, it seems to me that the ResponseData is more like the 
&gt; following...
&gt; 
&gt; ResponseData ::= SEQUENCE {   
&gt; responderID          [1] EXPLICIT ResponderID,  
&gt; producedAt               GeneralizedTime,  
&gt; responses                SEQUENCE OF SingleResponse,  
&gt; responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
&gt; 
&gt; instead of the one defined in the RFC 2560.
&gt; 
&gt; ResponseData ::= SEQUENCE {   
&gt; version              [0] EXPLICIT Version DEFAULT v1,  
&gt; responderID              ResponderID,  
&gt; producedAt               GeneralizedTime,  
&gt; responses                SEQUENCE OF SingleResponse,  
&gt; responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
&gt; 
&gt; Did I miss something here ? Would someone mind to clarify that for me ?
&gt; 

It could be OK based on DER.

The version field will normally be the DEFAULT value (v1) and it will 
thus be omitted.

The ResponderID is a CHOICE type:

    ResponderID ::= CHOICE {
       byName               [1] Name,
       byKey                [2] KeyHash }

If the Name option is present then there will be [1] EXPLICIT preceding 
the Name structure (the default module tagging is EXPLICIT).

Steve.</I></FONT></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-qImNrHit6eSqeEgrhjsP--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12I1cE3028399; Mon, 2 Feb 2004 10:01:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12I1caM028398; Mon, 2 Feb 2004 10:01:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12I1afh028391 for <[e-mail]>; Mon, 2 Feb 2004 10:01:36 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=drh-consultancy.co.uk) by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1) id 1AniO6-000AdE-0V; Mon, 02 Feb 2004 18:01:34 +0000
Message-ID: <[e-mail]>
Date: Mon, 02 Feb 2004 18:02:16 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kwok Lee <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Question on OCSP response....
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kwok Lee wrote:

> Hi all,
> 
> I am not sure it is the place for this question. If not, hopefully, 
> someone can direct me to the right place.
> Anyway, I am currently implementing a OCSP client, and I am using the 
> openvalidation.org's public ocsp responder (ocsp.openvalidation.org) to 
> verify my implementation. I am having a problem on the OCSP response I 
> get from the responder. When I use dumpasn1 to decode the 
> BasicOCSPResponse, it seems to me that the ResponseData is more like the 
> following...
> 
> ResponseData ::= SEQUENCE {   
> responderID          [1] EXPLICIT ResponderID,  
> producedAt               GeneralizedTime,  
> responses                SEQUENCE OF SingleResponse,  
> responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
> 
> instead of the one defined in the RFC 2560.
> 
> ResponseData ::= SEQUENCE {   
> version              [0] EXPLICIT Version DEFAULT v1,  
> responderID              ResponderID,  
> producedAt               GeneralizedTime,  
> responses                SEQUENCE OF SingleResponse,  
> responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
> 
> Did I miss something here ? Would someone mind to clarify that for me ?
> 

It could be OK based on DER.

The version field will normally be the DEFAULT value (v1) and it will 
thus be omitted.

The ResponderID is a CHOICE type:

    ResponderID ::= CHOICE {
       byName               [1] Name,
       byKey                [2] KeyHash }

If the Name option is present then there will be [1] EXPLICIT preceding 
the Name structure (the default module tagging is EXPLICIT).

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12HfVQI025685; Mon, 2 Feb 2004 09:41:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12HfU1o025684; Mon, 2 Feb 2004 09:41:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12HfTI2025678 for <[e-mail]>; Mon, 2 Feb 2004 09:41:29 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA16405; Mon, 2 Feb 2004 18:41:29 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 2 Feb 2004 18:41:29 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i12HfSK22394; Mon, 2 Feb 2004 18:41:28 +0100 (MET)
Date: Mon, 2 Feb 2004 18:41:28 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Question on OCSP response....
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since version is always v1 in actual code, and the encoding is DER,
and assumed thet one only sees the Name choice, then a
syntax of

ResponseData ::= SEQUENCE {   
responderID          [1] EXPLICIT Name,  -- and not [1] ResponderID
producedAt               GeneralizedTime,  
responses                SEQUENCE OF SingleResponse,  
responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

would also parse any actual response.


> Hi,
> 
> Could you post a base 64 or hex encoded response structure you that is 
> exhibiting this improper encoding to the group?
> 
> Thx,
> Bryan Pitcher
> 
> Kwok Lee wrote:
> 
> > Hi all,
> >
> > I am not sure it is the place for this question. If not, hopefully, 
> > someone can direct me to the right place.
> > Anyway, I am currently implementing a OCSP client, and I am using the 
> > openvalidation.org's public ocsp responder (ocsp.openvalidation.org) 
> > to verify my implementation. I am having a problem on the OCSP 
> > response I get from the responder. When I use dumpasn1 to decode the 
> > BasicOCSPResponse, it seems to me that the ResponseData is more like 
> > the following...
> >
> > ResponseData ::= SEQUENCE {   
> > responderID          [1] EXPLICIT ResponderID,  
> > producedAt               GeneralizedTime,  
> > responses                SEQUENCE OF SingleResponse,  
> > responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
> >
> > instead of the one defined in the RFC 2560.
> >
> > ResponseData ::= SEQUENCE {   
> > version              [0] EXPLICIT Version DEFAULT v1,  
> > responderID              ResponderID,  
> > producedAt               GeneralizedTime,  
> > responses                SEQUENCE OF SingleResponse,  
> > responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
> >
> > Did I miss something here ? Would someone mind to clarify that for me ?
> >
> > Appreciate and thanks for any help...
> > kc
> >
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12GweMr021779; Mon, 2 Feb 2004 08:58:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12Gwe1J021778; Mon, 2 Feb 2004 08:58:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12Gwdfr021767 for <[e-mail]>; Mon, 2 Feb 2004 08:58:39 -0800 (PST) (envelope-from [e-mail])
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id i12GwXo14583; Mon, 2 Feb 2004 09:58:33 -0700 (MST)
Received: from binor.com ([208.30.65.80]) (authenticated bits=0) by smtp.digsigtrust.com (8.12.6/8.12.6) with ESMTP id i12GnQa0006261; Mon, 2 Feb 2004 09:58:27 -0700 (MST)
Message-ID: <[e-mail]>
Date: Mon, 02 Feb 2004 09:47:24 -0700
From: Bryan Pitcher <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kwok Lee <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Question on OCSP response....
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Could you post a base 64 or hex encoded response structure you that is 
exhibiting this improper encoding to the group?

Thx,
Bryan Pitcher

Kwok Lee wrote:

> Hi all,
>
> I am not sure it is the place for this question. If not, hopefully, 
> someone can direct me to the right place.
> Anyway, I am currently implementing a OCSP client, and I am using the 
> openvalidation.org's public ocsp responder (ocsp.openvalidation.org) 
> to verify my implementation. I am having a problem on the OCSP 
> response I get from the responder. When I use dumpasn1 to decode the 
> BasicOCSPResponse, it seems to me that the ResponseData is more like 
> the following...
>
> ResponseData ::= SEQUENCE {   
> responderID          [1] EXPLICIT ResponderID,  
> producedAt               GeneralizedTime,  
> responses                SEQUENCE OF SingleResponse,  
> responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
>
> instead of the one defined in the RFC 2560.
>
> ResponseData ::= SEQUENCE {   
> version              [0] EXPLICIT Version DEFAULT v1,  
> responderID              ResponderID,  
> producedAt               GeneralizedTime,  
> responses                SEQUENCE OF SingleResponse,  
> responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
>
> Did I miss something here ? Would someone mind to clarify that for me ?
>
> Appreciate and thanks for any help...
> kc
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12FvSq0017077; Mon, 2 Feb 2004 07:57:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i12FvSmE017076; Mon, 2 Feb 2004 07:57:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12FvQVb017061 for <[e-mail]>; Mon, 2 Feb 2004 07:57:27 -0800 (PST) (envelope-from [e-mail])
Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i12FvLR02980 for <[e-mail]>; Mon, 2 Feb 2004 10:57:21 -0500 (EST)
Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <CZNTTK2Z>; Mon, 2 Feb 2004 10:57:20 -0500
Message-ID: <[e-mail]>
From: "Kwok Lee" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Question on OCSP response....
Date: Mon, 2 Feb 2004 10:57:20 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E9A5.3D17F804"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C3E9A5.3D17F804
Content-Type: text/plain

Hi all,

I am not sure it is the place for this question. If not, hopefully, someone
can direct me to the right place.
Anyway, I am currently implementing a OCSP client, and I am using the
openvalidation.org's public ocsp responder (ocsp.openvalidation.org) to
verify my implementation. I am having a problem on the OCSP response I get
from the responder. When I use dumpasn1 to decode the BasicOCSPResponse, it
seems to me that the ResponseData is more like the following...

ResponseData ::= SEQUENCE {    
responderID          [1] EXPLICIT ResponderID,   
producedAt               GeneralizedTime,   
responses                SEQUENCE OF SingleResponse,   
responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

instead of the one defined in the RFC 2560.

ResponseData ::= SEQUENCE {    
version              [0] EXPLICIT Version DEFAULT v1,   
responderID              ResponderID,   
producedAt               GeneralizedTime,   
responses                SEQUENCE OF SingleResponse,   
responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

Did I miss something here ? Would someone mind to clarify that for me ?

Appreciate and thanks for any help...
kc

------_=_NextPart_001_01C3E9A5.3D17F804
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>Question on OCSP response....</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I am not sure it is the place for this =
question. If not, hopefully, someone can direct me to the right =
place.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Anyway, I am currently implementing a =
OCSP client, and I am using the openvalidation.org's public ocsp =
responder (ocsp.openvalidation.org) to verify my implementation. I am =
having a problem on the OCSP response I get from the responder. When I =
use dumpasn1 to decode the BasicOCSPResponse, it seems to me that the =
ResponseData is more like the following...</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">ResponseData ::=3D SEQUENCE =
{&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">responderID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; [1] EXPLICIT ResponderID,&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">producedAt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GeneralizedTime,&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">responses&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SEQUENCE OF =
SingleResponse,&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">responseExtensions&nbsp;&nbsp; [1] =
EXPLICIT Extensions OPTIONAL }</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">instead of the one defined in the RFC =
2560.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">ResponseData ::=3D SEQUENCE =
{&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">version&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; [0] EXPLICIT Version DEFAULT =
v1,&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">responderID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ResponderID,&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">producedAt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GeneralizedTime,&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">responses&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SEQUENCE OF =
SingleResponse,&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">responseExtensions&nbsp;&nbsp; [1] =
EXPLICIT Extensions OPTIONAL }</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Did I miss something here ? Would =
someone mind to clarify that for me ?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Appreciate and thanks for any =
help...</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">kc</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3E9A5.3D17F804--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i129HHU1063506; Mon, 2 Feb 2004 01:17:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i129HHxe063505; Mon, 2 Feb 2004 01:17:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-2-sn4.m-sp.skanova.net (av7-2-sn4.m-sp.skanova.net [81.228.10.109]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i129HG3C063450 for <[e-mail]>; Mon, 2 Feb 2004 01:17:16 -0800 (PST) (envelope-from [e-mail])
Received: by av7-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id B63C837E48; Mon,  2 Feb 2004 10:17:08 +0100 (CET)
Received: from smtp2.fre.skanova.net (smtp2.fre.skanova.net [195.67.227.95]) by av7-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 92F7737E48; Mon,  2 Feb 2004 10:17:08 +0100 (CET)
Received: from arport (t9o913p93.telia.com [213.64.27.93]) by smtp2.fre.skanova.net (8.12.10/8.12.10) with SMTP id i129H6VM010818; Mon, 2 Feb 2004 10:17:07 +0100 (CET)
Message-ID: <006b01c3e96c$8b51f5d0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Solved:Last Call: 'Qualified Certificates Profile' to Proposed Standard
Date: Mon, 2 Feb 2004 10:11:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear list,

Stefan has in a private mail clarified the situation and we are in
agreement that IETF draft does NOT suffer from the deficiency that
I mentioned.

It is rather ETSI's profiling of RFC3039bis that suffers from what
I consider is a "kludge" by [more or less] requiring a particular
"QC detector" mechanism in relying party applications. 

Why ETSI did rather not exploit the policy system for this function? 
Well, that's a rather long and hairy story that run through the
"anders-draft-translation-engine" returns the single line:

                           because the policy system suxx.

Best
Anders R



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i128twPp054945; Mon, 2 Feb 2004 00:55:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i128twR6054943; Mon, 2 Feb 2004 00:55:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan02.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.11/8.12.8) with SMTP id i128trJc054900 for <[e-mail]>; Mon, 2 Feb 2004 00:55:56 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 13263 invoked by alias); 2 Feb 2004 08:55:50 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 13199 invoked by alias); 2 Feb 2004 08:55:47 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2004 08:55:47 -0000
Received: (qmail 19715 invoked from network); 2 Feb 2004 08:55:46 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 2 Feb 2004 08:55:46 -0000
Date: Mon, 02 Feb 2004 17:56:12 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Subject: Re[2]: UTF-8 encoding after December 31 2003
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, "Tim Polk" <[e-mail]>, "Russ Housley" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.07.04 [ja]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

=== 4.1.2.4 of RFC 3280:

Exceptions to the December 31, 2003 UTF8 encoding requirements are as
follows:

   (a)  CAs MAY issue "name rollover" certificates to support an
   orderly migration to UTF8String encoding.  Such certificates would
   include the CA's UTF8String encoded name as issuer and and the old
   name encoding as subject, or vice-versa.

   (b)  As stated in section 4.1.2.6, the subject field MUST be
   populated with a non-empty distinguished name matching the
   contents of the issuer field in all certificates issued by the
   subject CA regardless of encoding.
===


I guess that exception (a) is only applied for a CA issued self-signed
certificate. But exception (b) is able to be applied for all CAs, such
as subordinate CA and root CA.
# Subordinate CA means that has no self-signed certificate.
If we can apply (b) to any CAs, all CAs do not require to issue "name
rollover" certificate. If authors hope to apply the exception (b) to
only a subordinate CA, they need to add some description.

> Question: 
> 
> Is it OK to issue certificates from that CA that has an Issuer name
> matching the subject name of the existing CA certificate (in old
> encoding)?

Stefan, I think therefore it is okay to a subordinate CA at least.
But, it may be not okay to only root CA.


BTW, I have a question to exception (b).
I guess that exception (b) means that an issuer DN is encoded by old
encoding type in all issued certificate, even though the subject DN is
encoded by UTF-8.

See the following case:

Subordinate CA cert issued by CA-X before 2003:
    issuer: CA-X (Printable)
    subject: CA-Y (Printable)

EE cert issued by CA-Y after 2004:
    issuer: CA-Y (Printable)
    subject: EE-Z (UTF-8)

Is it correct?

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11KJNRN056105; Sun, 1 Feb 2004 12:19:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i11KJNDO056104; Sun, 1 Feb 2004 12:19:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11KJLkE056097 for <[e-mail]>; Sun, 1 Feb 2004 12:19:21 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 Feb 2004 20:19:17 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 01 Feb 2004 20:19:17 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 Feb 2004 20:19:17 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: SV: Last Call: 'Qualified Certificates Profile' to Proposed Standard
Date: Sun, 1 Feb 2004 20:15:52 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Last Call: 'Qualified Certificates Profile' to Proposed Standard
Thread-Index: AcPo+wLyHPnfA7I2RN+1QHZ9tBbH6QABS2mF
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 01 Feb 2004 20:19:17.0033 (UTC) FILETIME=[AABD9990:01C3E900]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i11KJMkE056099
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Its defined in the policy section and we also agreed to clarify this further as part of our response to Denis.
 
I can't further respond your oposition to something the standard isn't doing, providing or claiming.
 
/Stefan

________________________________

Från: Anders Rundgren [mailto:[e-mail]]
Skickat: sö 2/1/2004 8:33
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Qualified Certificates Profile' to Proposed Standard



Stefan,

>qcStatement is a mechanism to highlight aspects already defined by policy.
>It is NOT a mechanism to create variations of the same policy.

But there is absolutely nothing in the draft supporting these claims.

Your ETSI posting on qcStatements mentioned a programmatic policy
module which is completely redundant if qcStatements are just
"clarifications" (i.e. repeating things that you can read about in the
CP documents).

>qcStatement is NOT part of path validation.

I never said that.  But IF qcStatements are used for trust differention
regardless if the validator is human or machine, it is indeed
an extra validation procedure, but outside of RFC3280.

>It is a bit late to discuss the existence of this extension since it
>has been defined by RFC 3039 and has been in use for several
>years by now.

This is indeed true, but don't you think that adding your two initial
claims to the draft would create HUGE opposition?

I rather believe that this mechanism is a way for QC CAs to introduce
NEW stuff under a given policy, without having to create a new CA.
This is IMHO pushing CA related problems on relying parties which
does not seem to be a particularly good idea as the latter typically
outnumber the former by 2-6 magnitudes.

Anders
________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: sö 2/1/2004 10:45
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Qualified Certificates Profile' to Proposed Standard




Stefan,

qcStatements are from a software point of view equivalent to warranty extensions.

That is, these constructs introduce a mechanism to allow certain issuance
qualities to be variant under a given policy.

This works great assuming that the relying party is a human being,
probably subscribed to the PKIX-list, and who's main passion is
switching between the applications "Certificate Properties" and
www.nudity.com.

However, for those who like me, rather focus on the other part of the
available market (=99.99999%), such mechanisms instead of "increasing
trust", contribute to costs, hassles and limited customer acceptance.

Yes, even security is put at risk as a system that is hard to understand
and manage, no matter how smart it seems to be, is likely to occasionally
be mis-configured, by the maybe not always so smart system administrators.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:38
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Your are posting to the wrong list.
There is nothing in the IETF profile that mandates use of qcStatement extension.

/Stefan

________________________________

Från: Anders Rundgren [mailto:[e-mail]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard



Stefan,

You are perfectly right, the document says nothing about this.

But You did in a recent ETSI posting:

     "The purpose of the qcStatement is to be used AFTER successful path
      validation to support programmatic detection if the certificate should be
     accepted as a QC or not"

     "The consumer of this function could be a UI display function or some
       policy module determining the suitability of a certificate for a certain purpose"

But "programmatic detection if a certificate should be accepted as
a QC or not" is equivalent to a extra path-validation step.

This requires nothing less than a tree-dimensional trust-config/admin
system (trust anchor, existing policy management, qcStatements).

If an automated recipient does not support all three it can hardly call
itself QC-compliant, making this functionality a MUST regardless if
extensions are marked critical or not.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:17
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Anders,



After reading this a couple of times I still don't have a clue what your problem with the document is.

I'm not aware of any part of the document promoting the kind of behaviour you are talking about.



/Stefan

________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard




Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders












Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11Jcpd3053763; Sun, 1 Feb 2004 11:38:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i11JcpI7053762; Sun, 1 Feb 2004 11:38:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av5-1-sn1.fre.skanova.net (av5-1-sn1.fre.skanova.net [81.228.11.111]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11Jco27053752 for <[e-mail]>; Sun, 1 Feb 2004 11:38:50 -0800 (PST) (envelope-from [e-mail])
Received: by av5-1-sn1.fre.skanova.net (Postfix, from userid 502) id 78C9D37F47; Sun,  1 Feb 2004 20:38:46 +0100 (CET)
Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av5-1-sn1.fre.skanova.net (Postfix) with ESMTP id 696F037F45 for <[e-mail]>; Sun,  1 Feb 2004 20:38:46 +0100 (CET)
Received: from arport (t10o913p18.telia.com [213.64.27.138]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 88C3937E55; Sun,  1 Feb 2004 20:38:44 +0100 (CET)
Message-ID: <013301c3e8fa$38d3d2a0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Last Call: 'Qualified Certificates Profile' to Proposed Standard
Date: Sun, 1 Feb 2004 20:33:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

>qcStatement is a mechanism to highlight aspects already defined by policy.
>It is NOT a mechanism to create variations of the same policy.

But there is absolutely nothing in the draft supporting these claims.

Your ETSI posting on qcStatements mentioned a programmatic policy
module which is completely redundant if qcStatements are just
"clarifications" (i.e. repeating things that you can read about in the
CP documents).

>qcStatement is NOT part of path validation.

I never said that.  But IF qcStatements are used for trust differention
regardless if the validator is human or machine, it is indeed
an extra validation procedure, but outside of RFC3280.

>It is a bit late to discuss the existence of this extension since it
>has been defined by RFC 3039 and has been in use for several
>years by now.

This is indeed true, but don't you think that adding your two initial
claims to the draft would create HUGE opposition?

I rather believe that this mechanism is a way for QC CAs to introduce
NEW stuff under a given policy, without having to create a new CA.
This is IMHO pushing CA related problems on relying parties which
does not seem to be a particularly good idea as the latter typically
outnumber the former by 2-6 magnitudes.

Anders
________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: sö 2/1/2004 10:45
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Qualified Certificates Profile' to Proposed Standard




Stefan,

qcStatements are from a software point of view equivalent to warranty extensions.

That is, these constructs introduce a mechanism to allow certain issuance
qualities to be variant under a given policy.

This works great assuming that the relying party is a human being,
probably subscribed to the PKIX-list, and who's main passion is
switching between the applications "Certificate Properties" and
www.nudity.com.

However, for those who like me, rather focus on the other part of the
available market (=99.99999%), such mechanisms instead of "increasing
trust", contribute to costs, hassles and limited customer acceptance.

Yes, even security is put at risk as a system that is hard to understand
and manage, no matter how smart it seems to be, is likely to occasionally
be mis-configured, by the maybe not always so smart system administrators.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:38
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Your are posting to the wrong list.
There is nothing in the IETF profile that mandates use of qcStatement extension.

/Stefan

________________________________

Från: Anders Rundgren [mailto:[e-mail]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard



Stefan,

You are perfectly right, the document says nothing about this.

But You did in a recent ETSI posting:

     "The purpose of the qcStatement is to be used AFTER successful path
      validation to support programmatic detection if the certificate should be
     accepted as a QC or not"

     "The consumer of this function could be a UI display function or some
       policy module determining the suitability of a certificate for a certain purpose"

But "programmatic detection if a certificate should be accepted as
a QC or not" is equivalent to a extra path-validation step.

This requires nothing less than a tree-dimensional trust-config/admin
system (trust anchor, existing policy management, qcStatements).

If an automated recipient does not support all three it can hardly call
itself QC-compliant, making this functionality a MUST regardless if
extensions are marked critical or not.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:17
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Anders,



After reading this a couple of times I still don't have a clue what your problem with the document is.

I'm not aware of any part of the document promoting the kind of behaviour you are talking about.



/Stefan

________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard




Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders









Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11HwKdJ047500; Sun, 1 Feb 2004 09:58:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i11HwKaT047499; Sun, 1 Feb 2004 09:58:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11HwIwI047491 for <[e-mail]>; Sun, 1 Feb 2004 09:58:19 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 Feb 2004 17:58:06 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 01 Feb 2004 17:58:06 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 Feb 2004 17:58:05 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: SV: Last Call: 'Qualified Certificates Profile' to Proposed Standard
Date: Sun, 1 Feb 2004 17:58:23 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Last Call: 'Qualified Certificates Profile' to Proposed Standard
Thread-Index: AcPos/5cpG2C7bpeSl+wKzsqeKSu7AAN1J0s
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 01 Feb 2004 17:58:05.0937 (UTC) FILETIME=[F192EE10:01C3E8EC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i11HwJwI047494
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

 

qcStatement is a mechanism to highlight aspects already defined by policy. It is NOT a mechanism to create variations of the same policy. qcStatement is NOT part of path validation.

 

It is a bit late to discuss the existence of this extension since it has been defined by RFC 3039 and has been in use for several years by now. 

 

/Stefan

________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: sö 2/1/2004 10:45
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Qualified Certificates Profile' to Proposed Standard




Stefan,

qcStatements are from a software point of view equivalent to warranty extensions.

That is, these constructs introduce a mechanism to allow certain issuance
qualities to be variant under a given policy.

This works great assuming that the relying party is a human being,
probably subscribed to the PKIX-list, and who's main passion is
switching between the applications "Certificate Properties" and
www.nudity.com.

However, for those who like me, rather focus on the other part of the
available market (=99.99999%), such mechanisms instead of "increasing
trust", contribute to costs, hassles and limited customer acceptance.

Yes, even security is put at risk as a system that is hard to understand
and manage, no matter how smart it seems to be, is likely to occasionally
be mis-configured, by the maybe not always so smart system administrators.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:38
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Your are posting to the wrong list.
There is nothing in the IETF profile that mandates use of qcStatement extension.

/Stefan

________________________________

Från: Anders Rundgren [mailto:[e-mail]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard



Stefan,

You are perfectly right, the document says nothing about this.

But You did in a recent ETSI posting:

     "The purpose of the qcStatement is to be used AFTER successful path
      validation to support programmatic detection if the certificate should be
     accepted as a QC or not"

     "The consumer of this function could be a UI display function or some
       policy module determining the suitability of a certificate for a certain purpose"

But "programmatic detection if a certificate should be accepted as
a QC or not" is equivalent to a extra path-validation step.

This requires nothing less than a tree-dimensional trust-config/admin
system (trust anchor, existing policy management, qcStatements).

If an automated recipient does not support all three it can hardly call
itself QC-compliant, making this functionality a MUST regardless if
extensions are marked critical or not.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:17
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Anders,



After reading this a couple of times I still don't have a clue what your problem with the document is.

I'm not aware of any part of the document promoting the kind of behaviour you are talking about.



/Stefan

________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard




Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders










Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i119pGiV007897; Sun, 1 Feb 2004 01:51:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i119pGDa007896; Sun, 1 Feb 2004 01:51:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av9-2-sn1.fre.skanova.net (av9-2-sn1.fre.skanova.net [81.228.11.116]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i119pEMN007844 for <[e-mail]>; Sun, 1 Feb 2004 01:51:15 -0800 (PST) (envelope-from [e-mail])
Received: by av9-2-sn1.fre.skanova.net (Postfix, from userid 502) id 5943037E96; Sun,  1 Feb 2004 10:51:07 +0100 (CET)
Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av9-2-sn1.fre.skanova.net (Postfix) with ESMTP id 4ABCE37E5A for <[e-mail]>; Sun,  1 Feb 2004 10:51:07 +0100 (CET)
Received: from arport (t11o913p63.telia.com [213.64.28.63]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 9C40A37E5E; Sun,  1 Feb 2004 10:51:05 +0100 (CET)
Message-ID: <006e01c3e8a8$20b7ebe0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Last Call: 'Qualified Certificates Profile' to Proposed Standard
Date: Sun, 1 Feb 2004 10:45:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

qcStatements are from a software point of view equivalent to warranty extensions.

That is, these constructs introduce a mechanism to allow certain issuance
qualities to be variant under a given policy.

This works great assuming that the relying party is a human being,
probably subscribed to the PKIX-list, and who's main passion is
switching between the applications "Certificate Properties" and
www.nudity.com.

However, for those who like me, rather focus on the other part of the
available market (=99.99999%), such mechanisms instead of "increasing
trust", contribute to costs, hassles and limited customer acceptance.

Yes, even security is put at risk as a system that is hard to understand
and manage, no matter how smart it seems to be, is likely to occasionally
be mis-configured, by the maybe not always so smart system administrators.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:38
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Your are posting to the wrong list.
There is nothing in the IETF profile that mandates use of qcStatement extension.

/Stefan

________________________________

Från: Anders Rundgren [mailto:[e-mail]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard



Stefan,

You are perfectly right, the document says nothing about this.

But You did in a recent ETSI posting:

     "The purpose of the qcStatement is to be used AFTER successful path
      validation to support programmatic detection if the certificate should be
     accepted as a QC or not"

     "The consumer of this function could be a UI display function or some
       policy module determining the suitability of a certificate for a certain purpose"

But "programmatic detection if a certificate should be accepted as
a QC or not" is equivalent to a extra path-validation step.

This requires nothing less than a tree-dimensional trust-config/admin
system (trust anchor, existing policy management, qcStatements).

If an automated recipient does not support all three it can hardly call
itself QC-compliant, making this functionality a MUST regardless if
extensions are marked critical or not.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:17
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Anders,



After reading this a couple of times I still don't have a clue what your problem with the document is.

I'm not aware of any part of the document promoting the kind of behaviour you are talking about.



/Stefan

________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard




Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders