Subject: WG Last Call closed: PK algs

From: [email-masked]
Date: Sun, 29 Feb 2004 11:49:19 -0500

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

Date: Sun, 29 Feb 2004 11:49:19 -0500
From: [email-masked]
To: [email-masked], [email-masked]
Cc: Steven Bellovin <[email-masked]>, Russell Housley <[email-masked]>
Subject: WG Last Call closed: PK algs
Sender: [email-masked]

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

From: The IESG <[email-masked]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, <[email-masked]>
Subject: Protocol Action: 'X.509 Extensions for IP Addresses and AS  Identifiers' to Proposed Standard 
Date: Fri, 27 Feb 2004 23:06:55 -0500
Sender: [email-masked]

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.

Date: Fri, 27 Feb 2004 12:04:01 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: OMA's signText: No Policy OID
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: OMA's signText: No Policy OID
Date: Thu, 26 Feb 2004 19:53:57 +0100
Sender: [email-masked]

"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

Date: Thu, 26 Feb 2004 12:23:47 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: agenda, from Tim
Sender: [email-masked]

PKIX WG (pkix-wg)

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

CHAIR: Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Jongwook Park'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-02.txt
Date: Wed, 25 Feb 2004 16:48:49 -0800
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Jongwook Park
Sent: Wednesday, February 25, 2004 5:26 AM
To: [email-masked]
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Jim Schaad
Sent: Wednesday, February 25, 2004 6:51 AM
To: [email-masked]; 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"

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

Date: Thu, 19 Feb 2004 00:41:20 +1300
From: Peter Gutmann <[email-masked]>
To: [email-masked]
Subject: RE: No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509
Sender: [email-masked]

"Al Arsenault" <[email-masked]> 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.

To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "David Cross" <[email-masked]>
Subject: Re: TLS:  No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Reply-To: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: 17 Feb 2004 08:44:00 -0800
Lines: 20
Sender: [email-masked]

"Anders Rundgren" <[email-masked]> 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

Date: Tue, 17 Feb 2004 16:11:22 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: No policy OID. Was: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Tue, 17 Feb 2004 08:16:29 -0500, "Al Arsenault" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Anders Rundgren" <[email-masked]>
To: "EKR" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "David Cross" <[email-masked]>
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
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: "EKR" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "David Cross" <[email-masked]>
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
Sender: [email-masked]

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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Santosh Chokhani" <[email-masked]>; "David Cross"
<[email-masked]>
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" <[email-masked]> 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

Date: Tue, 17 Feb 2004 12:36:24 -0600 (CST)
From: Eric Norman <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Re: TLS:  No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Sender: [email-masked]

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

---2140662931-2103392603-1077042988=:17744--

Date: Tue, 17 Feb 2004 15:29:29 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: TLS: No policy OID. Was: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

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

pgut001> 
pgut001> Richard Levitte - VMS Whacker <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Tue, 17 Feb 2004 09:37:30 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: TLS:  No policy OID.  Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Cc: <[email-masked]>, <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "David Cross" <[email-masked]>
Sender: [email-masked]

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

From: "Jongwook Park" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-sim-02.txt
Date: Wed, 25 Feb 2004 22:26:03 +0900
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Jim Schaad
Sent: Wednesday, February 25, 2004 6:51 AM
To: [email-masked]; 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: +82-2-405-5432
   Email: [email-masked]

   Jaeho Yoon
   Korea Information Security Agency
   Phone: +82-2-405-5434
   Email: [email-masked]

   Seungjoo Kim
   Korea Information Security Agency
   Phone: +82-2-405-5440
   Email: [email-masked]

   Jaeil Lee
   Korea Information Security Agency
   Phone: +82-2-405-5300
   Email: [email-masked]

   Sangjoon, Park
   BCQRE
   467-12, Dogok-Dong, Kangnam-Gu, Seoul, 135-270
   REPUBLIC OF KOREA
   Phone: +82-2-3453-1114 (Ext. 200)
   EMail: [email-masked]

   Hongsub, Lee
   Internet Security Technology Forum
   78, Garak-Dong, Songpa-Gu, Seoul, 138-803
   REPUBLIC OF KOREA
   Phone: +82-2-405-5200
   EMail: [email-masked]

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

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, "IETF-PKIX" <[email-masked]>
Subject: Comments on draft-ietf-pkix-sim-02.txt
Date: Tue, 24 Feb 2004 13:51:05 -0800
Sender: [email-masked]

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"

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

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>
Subject: Relationship between SAN and IAN?
Date: Tue, 24 Feb 2004 11:04:24 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

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

Date: Mon, 23 Feb 2004 15:26:32 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-sonof3039 is Approved 
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: draft-ietf-pkix-sonof3039 is Approved
Date: Mon, 23 Feb 2004 20:01:45 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Denis,

Some corrections below;

/Stefan

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

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 23 februari 2004 17:59
> To: Russ Housley
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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 <[email-masked]>
> >> From: Stephen Kent <[email-masked]>
> >> Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
> >> Cc: "Stefan Santesson" <[email-masked]>, "Tim Polk"
> >> <[email-masked]>,
> >>    "Magnus Nystrom" <[email-masked]>, Stephen  Kent
> >> <[email-masked]>
> >>
> >> 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
> >>
> >
> >
> 

Date: Mon, 23 Feb 2004 12:38:52 -0500
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: draft-ietf-pkix-sonof3039 is Approved
Cc: Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Mon, 23 Feb 2004 12:36:26 -0500
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-sonof3039 is Approved
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Mon, 23 Feb 2004 12:35:30 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: draft-ietf-pkix-sonof3039 is Approved
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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 <[email-masked]>
>From: Stephen Kent <[email-masked]>
>Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
>Cc: "Stefan Santesson" <[email-masked]>, "Tim Polk" <[email-masked]>,
>    "Magnus Nystrom" <[email-masked]>, Stephen  Kent <[email-masked]>
>
>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

Date: Mon, 23 Feb 2004 17:58:59 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-sonof3039 is Approved
Sender: [email-masked]

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 <[email-masked]>
>> From: Stephen Kent <[email-masked]>
>> Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
>> Cc: "Stefan Santesson" <[email-masked]>, "Tim Polk" 
>> <[email-masked]>,
>>    "Magnus Nystrom" <[email-masked]>, Stephen  Kent 
>> <[email-masked]>
>>
>> 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
>>
> 
> 

Date: Mon, 23 Feb 2004 14:45:09 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>
CC: [email-masked], Magnus Nystrom <[email-masked]>, Tim Polk <[email-masked]>, Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
Sender: [email-masked]

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:[email-masked]]
> 
> Sent: den 26 januari 2004 10:05
> 
> To: Stefan Santesson; Tim Polk; Magnus Nystrom
> 
> Cc: [email-masked]
> 
> 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)
> 
>  
> 
>  
> 
>  
> 

To: IETF-Announce: ;
Subject: RFC 3709 on Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 19 Feb 2004 10:57:54 -0800
Sender: [email-masked]

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

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: 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: <[email-masked]>

--OtherAccess--
--NextPart--

From: "Anders Rundgren" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
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
Sender: [email-masked]

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

From: "Jongwook Park" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Too Many Authors: draft-ietf-pkix-sim-02.txt
Date: Wed, 18 Feb 2004 11:03:36 +0900
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Wednesday, February 18, 2004 8:55 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
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>

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "IETF-PKIX" <[email-masked]>
Subject: Comments on draft-ietf-pkix-sim-02.txt
Date: Tue, 17 Feb 2004 18:50:06 -0800
Sender: [email-masked]

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

Date: Wed, 18 Feb 2004 11:38:54 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Agenda Requests, Please...
Sender: [email-masked]

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

Date: Wed, 18 Feb 2004 14:58:43 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: TLS: No policy OID. Was: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <028701c3f577$34cc1850$0500a8c0@arport> on Tue, 17 Feb 2004 17:58:02 +0100, "Anders Rundgren" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Fri, 13 Feb 2004 17:35:58 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: new WG item
Sender: [email-masked]

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.

Date: Sat, 14 Feb 2004 00:45:43 +1300
From: Peter Gutmann <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-05.txt
Sender: [email-masked]

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

Subject: Re: Policy OID => CP mapping (was: Policy User Interfaces)
To: "Anders Rundgren" <[email-masked]>
Cc: "Richard Levitte - VMS Whacker" <[email-masked]>, [email-masked]
From: [email-masked]
Date: Fri, 13 Feb 2004 09:11:04 +0000
Sender: [email-masked]

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

Date: Thu, 12 Feb 2004 16:15:06 -0500
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: clarification of CRL processing in RFC3280
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
>Behalf Of Russ Housley
>Sent: Thursday, February 12, 2004 10:07 AM
>To: [email-masked]; [email-masked]
>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

From: "Anders Rundgren" <[email-masked]>
To: "Richard Levitte - VMS Whacker" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Policy OID => CP mapping (was: Policy User Interfaces)
Date: Thu, 12 Feb 2004 22:07:26 +0100
Sender: [email-masked]

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: [email-masked]=20
  To: Richard Levitte - VMS Whacker=20
  Cc: [email-masked]=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 <[email-masked]>

      =20

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

        To: [email-masked]
        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: +46-708-26 53 44 | | 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=[email-masked]=20
  =
href=3D"mailto:[email-masked]">[email-masked]</=
A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Richard Levitte - VMS Whacker</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> 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 =
<[email-masked]>"=20
  src=3D"cid:02cf01c3f1ac$37aba2d0$0500a8c0@arport" width=3D16>Richard =
Levitte - VMS=20
  Whacker &lt;[email-masked]&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__=[email-masked]); =
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;[email-masked]&gt;</FONT></B><BR><FONT size=3D2>Sent =
by:=20
                [email-masked]</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>[email-masked]</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: +46-708-26 53 44 | | 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--

Date: Thu, 12 Feb 2004 22:03:59 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Policy OID => CP mapping
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

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

levitte> In message <[email-masked]> on Thu, 12 Feb 2004 16:30:15 +0000, [email-masked] 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Thu, 12 Feb 2004 21:40:46 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Policy OID => CP mapping
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <01a101c3f193$9625c4d0$0500a8c0@arport> on Thu, 12 Feb 2004 19:11:06 +0100, "Anders Rundgren" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Thu, 12 Feb 2004 20:04:44 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Policy OID => CP mapping
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Thu, 12 Feb 2004 16:30:15 +0000, [email-masked] 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Key, Shawn (Contractor)" <[email-masked]>
To: "'Margus Freudenthal'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Policy User Interfaces
Date: Thu, 12 Feb 2004 13:49:52 -0500
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, February 12, 2004 10:45 AM
To: [email-masked]; [email-masked]
Subject: Re: Policy User Interfaces

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

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: clarification of CRL processing in RFC3280
Date: Thu, 12 Feb 2004 13:30:22 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Thursday, February 12, 2004 10:07 AM
To: [email-masked]; [email-masked]
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 

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, "Richard Levitte - VMS Whacker" <[email-masked]>
Subject: Re: Policy OID => CP mapping (was: Policy User Interfaces)
Date: Thu, 12 Feb 2004 19:11:06 +0100
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Anders Rundgren" <[email-masked]>
To: "Richard Levitte - VMS Whacker" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Policy User Interfaces
Date: Thu, 12 Feb 2004 17:55:13 +0100
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
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" <[email-masked]>
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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Subject: Re: Policy OID => CP mapping (was: Policy User Interfaces)
To: Richard Levitte - VMS Whacker <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Date: Thu, 12 Feb 2004 16:30:15 +0000
Sender: [email-masked]

--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                                                              
                      <[email-masked]>           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: +46-708-26 53 44 |                             | 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__=[email-masked]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for Richard Levitte - V=
MS Whacker &lt;[email-masked]&gt;">Richard Levitte - VMS Whacker &lt;lev=
[email-masked]&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=
[email-masked]" border=3D"0" height=3D"1" width=3D"72" al=
t=3D""><br>
</td><td style=3D"background-image:url(cid:30__=3D8FBBE4ABDFCA19078f9e8=
[email-masked]); background-repeat: no-repeat; " width=3D"1%"><img=
 src=3D"cid:20__=[email-masked]" 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;[email-masked]=
&gt;</font></b><br>
<font size=3D"2">Sent by: [email-masked]</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=
[email-masked]" 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">[email-masked]</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: +46-708-26 53 44 |                             | 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__=[email-masked]>
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__=[email-masked]>
Content-transfer-encoding: base64

R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7

--0__=8FBBE4ABDFCA19078f9e8a93df938690918c8FBBE4ABDFCA1907--

Date: Thu, 12 Feb 2004 11:15:41 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Policy User Interfaces
Sender: [email-masked]

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
> 

From: "Santosh Chokhani" <[email-masked]>
To: Stephen Kent <[email-masked]>, "Santosh Chokhani" <[email-masked]>
CC: <[email-masked]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Date: Thu, 12 Feb 2004 12:11:53 -0400
Sender: [email-masked]

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

Date: Thu, 12 Feb 2004 10:40:15 -0500
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 12 Feb 2004 17:44:38 +0200
From: Margus Freudenthal <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Policy User Interfaces
Sender: [email-masked]

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

Date: Thu, 12 Feb 2004 16:24:08 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Thu, 12 Feb 2004 14:20:48 +0000, [email-masked] 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Thu, 12 Feb 2004 16:22:50 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Thu, 12 Feb 2004 08:35:30 -0500, "Al Arsenault" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Thu, 12 Feb 2004 10:07:26 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: clarification of CRL processing in RFC3280
Sender: [email-masked]

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 

content-class: urn:content-classes:message
Subject: RE: Policy User Interfaces
Date: Thu, 12 Feb 2004 09:50:57 -0500
From: "Oshman, Dave" <[email-masked]>
To: <[email-masked]>, "Richard Levitte - VMS Whacker" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]=20
Sent: Thursday, February 12, 2004 9:21 AM
To: Richard Levitte - VMS Whacker
Cc: [email-masked]; [email-masked]
Subject: Re: Policy User Interfaces

 Richard Levitte - VMS Whacker <[email-masked]>

> 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> [email-masked]=20
[mailto:[email-masked]] <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
[email-masked]; [email-masked]<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 =
<[email-masked]>"=20
src=3D"cid:742394914@12022004-2AA4" width=3D16>Richard Levitte - VMS =
Whacker=20
&lt;[email-masked]&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--

Date: Thu, 12 Feb 2004 15:46:19 +0100 (CET)
To: [email-masked]
Subject: Policy OID => CP mapping (was: Policy User Interfaces)
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Subject: Re: Policy User Interfaces
To: Richard Levitte - VMS Whacker <[email-masked]>
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 12 Feb 2004 14:20:48 +0000
Sender: [email-masked]

--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__=[email-masked]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for Richard Levitte - V=
MS Whacker &lt;[email-masked]&gt;">Richard Levitte - VMS Whacker &lt;lev=
[email-masked]&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__=[email-masked]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4ABDFDDF0D58f9e8a93df938690918c8FBBE4ABDFDDF0D5--

Date: Thu, 12 Feb 2004 15:15:14 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <001c01c3f166$ba19b130$0500a8c0@arport> on Thu, 12 Feb 2004 13:49:39 +0100, "Anders Rundgren" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: clarification of CRL processing in RFC3280
Date: Thu, 12 Feb 2004 09:13:28 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Pierre
Sent: Thursday, February 12, 2004 2:32 AM
To: [email-masked]
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"

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

From: "Al Arsenault" <[email-masked]>
To: "Richard Levitte - VMS Whacker" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Policy User Interfaces
Date: Thu, 12 Feb 2004 08:35:30 -0500
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Richard Levitte - VMS
> Whacker
> Sent: Wednesday, February 11, 2004 4:55 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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

From: "Anders Rundgren" <[email-masked]>
To: "Richard Levitte - VMS Whacker" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Policy User Interfaces
Date: Thu, 12 Feb 2004 13:49:39 +0100
Sender: [email-masked]

>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

Date: Thu, 12 Feb 2004 13:08:24 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <017201c3f14b$16b6b620$0500a8c0@arport> on Thu, 12 Feb 2004 10:32:08 +0100, "Anders Rundgren" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Date: Thu, 12 Feb 2004 09:51:45 +0000
Sender: [email-masked]

--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__=[email-masked]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for &quot;Anders Rundgr=
en&quot; &lt;[email-masked]&gt;">&quot;Anders Rundgren&quot;=
 &lt;[email-masked]&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__=[email-masked]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4ABDFA6F3DD8f9e8a93df938690918c8FBBE4ABDFA6F3DD--

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

> 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

Date: Wed, 11 Feb 2004 23:31:45 -0800
From: Julien Pierre <[email-masked]>
Subject: clarification of CRL processing in RFC3280
To: [email-masked]
Reply-to: [email-masked]
Organization: America On-Line, Inc
Sender: [email-masked]

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

--------------ms090201030106080004050100--

From: "Deacon, Alex" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Deacon, Alex" <[email-masked]>
Subject: Changes to ocsp.verisign.com
Date: Wed, 11 Feb 2004 16:34:00 -0800
Sender: [email-masked]

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

[email-masked]

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Date: Wed, 11 Feb 2004 18:58:36 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Wednesday, February 11, 2004 3:22 PM
To: Santosh Chokhani
Cc: [email-masked]
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

Date: Wed, 11 Feb 2004 16:59:20 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Cc: "Guida, Richard [JJCUS]" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 11 Feb 2004 22:55:08 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

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

levitte> 
levitte> In message <[email-masked]> on Tue, 3 Feb 2004 10:04:55 -0500, "Al Arsenault" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, [email-masked]
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
Sender: [email-masked]

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

------_=_NextPart_001_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:  732 524 3785 

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Wednesday, February 11, 2004 3:50 PM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked]
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:[email-masked]> Richard [JJCUS] 
To: 'Anders Rundgren' <mailto:[email-masked]>  ; 'Santosh
<mailto:[email-masked]> Chokhani' ; [email-masked]
<mailto:[email-masked]>  
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:  732 524 3785 

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Wednesday, February 11, 2004 2:09 PM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked]
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:[email-masked]> Richard [JJCUS] 
To: 'Anders Rundgren' <mailto:[email-masked]>  ; 'Santosh
<mailto:[email-masked]> Chokhani' ; [email-masked]
<mailto:[email-masked]>  
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:  732 524 3785 

-----Original Message----- 
From: Anders Rundgren [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, February 11, 2004 2:43 AM 
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked] 
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:[email-masked]]<BR><B>Sent:</B> Wednesday, =
February 11,=20
  2004 3:50 PM<BR><B>To:</B> Guida, Richard [JJCUS]; 'Santosh =
Chokhani';=20
  [email-masked]<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=[email-masked] =
href=3D"mailto:[email-masked]">Guida,=20
    Richard [JJCUS]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">'Anders Rundgren'</A> ; =
<A=20
    title=[email-masked] =
href=3D"mailto:[email-masked]">'Santosh=20
    Chokhani'</A> ; <A title=[email-masked]=20
    href=3D"mailto:[email-masked]">[email-masked]</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:[email-masked]]<BR><B>Sent:</B> Wednesday, =
February 11,=20
      2004 2:09 PM<BR><B>To:</B> Guida, Richard [JJCUS]; 'Santosh =
Chokhani';=20
      [email-masked]<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=[email-masked] =
href=3D"mailto:[email-masked]">Guida,=20
        Richard [JJCUS]</A> </DIV>
        <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
        title=[email-masked]=20
        href=3D"mailto:[email-masked]">'Anders Rundgren'</A> =
; <A=20
        title=[email-masked] =
href=3D"mailto:[email-masked]">'Santosh=20
        Chokhani'</A> ; <A title=[email-masked]=20
        href=3D"mailto:[email-masked]">[email-masked]</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:[email-masked]">mailto:[email-masked]=
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
        [email-masked]</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--

Date: Wed, 11 Feb 2004 16:41:39 -0500
From: Steve Hanna <[email-masked]>
Subject: Will you support the PKI Action Plan?
To: PKIX List <[email-masked]>
Sender: [email-masked]

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

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

--------------msC3B17613BB9A7978AD5E5D37--

Date: Wed, 11 Feb 2004 16:39:53 -0500
From: Steve Hanna <[email-masked]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE,IIS, Outlook)
To: Al Arsenault <[email-masked]>
Cc: Peter Gutmann <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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

--------------msAEA4598C0092803B95115436--

Date: Wed, 11 Feb 2004 15:21:58 -0500
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 11 Feb 2004 13:43:45 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in  IE, IIS, Outlook)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 0:12 +1300 2/12/04, [email-masked] wrote:
>"Anders Rundgren" <[email-masked]> 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

From: "Anders Rundgren" <[email-masked]>
To: "Guida, Richard [JJCUS]" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
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
Sender: [email-masked]

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' ; [email-masked]=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:  732 524 3785=20

    -----Original Message-----
    From: Anders Rundgren [mailto:[email-masked]]
    Sent: Wednesday, February 11, 2004 2:09 PM
    To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked]
    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' ; [email-masked]=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:  732 524 3785=20

      -----Original Message-----=20
      From: Anders Rundgren [mailto:[email-masked]]=20
      Sent: Wednesday, February 11, 2004 2:43 AM=20
      To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked]=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=[email-masked] =
href=3D"mailto:[email-masked]">Guida,=20
  Richard [JJCUS]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">'Anders Rundgren'</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">'Santosh=20
  Chokhani'</A> ; <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</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:[email-masked]]<BR><B>Sent:</B> Wednesday, =
February 11,=20
    2004 2:09 PM<BR><B>To:</B> Guida, Richard [JJCUS]; 'Santosh =
Chokhani';=20
    [email-masked]<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=[email-masked] =
href=3D"mailto:[email-masked]">Guida,=20
      Richard [JJCUS]</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
      title=[email-masked]=20
      href=3D"mailto:[email-masked]">'Anders Rundgren'</A> ; =
<A=20
      title=[email-masked] =
href=3D"mailto:[email-masked]">'Santosh=20
      Chokhani'</A> ; <A title=[email-masked]=20
      href=3D"mailto:[email-masked]">[email-masked]</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:[email-masked]">mailto:[email-masked]=
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'; =

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-05.txt
Date: Wed, 11 Feb 2004 15:51:54 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure: 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-05.txt
Date: Wed, 11 Feb 2004 15:51:49 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure -- 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Date: Wed, 11 Feb 2004 21:33:40 +0100 (CET)
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Policy User Interfaces
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Tue, 3 Feb 2004 10:04:55 -0500, "Al Arsenault" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, [email-masked]
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
Sender: [email-masked]

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

------_=_NextPart_001_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:  732 524 3785 

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Wednesday, February 11, 2004 2:09 PM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked]
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:[email-masked]> Richard [JJCUS] 
To: 'Anders Rundgren' <mailto:[email-masked]>  ; 'Santosh
<mailto:[email-masked]> Chokhani' ; [email-masked]
<mailto:[email-masked]>  
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:  732 524 3785 

-----Original Message----- 
From: Anders Rundgren [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, February 11, 2004 2:43 AM 
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked] 
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:[email-masked]]<BR><B>Sent:</B> Wednesday, February 11, 
  2004 2:09 PM<BR><B>To:</B> Guida, Richard [JJCUS]; 'Santosh Chokhani'; 
  [email-masked]<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=[email-masked] href="mailto:[email-masked]">Guida, 
    Richard [JJCUS]</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>To:</B> <A title=[email-masked] 
    href="mailto:[email-masked]">'Anders Rundgren'</A> ; <A 
    title=[email-masked] href="mailto:[email-masked]">'Santosh 
    Chokhani'</A> ; <A title=[email-masked] 
    href="mailto:[email-masked]">[email-masked]</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:[email-masked]">mailto:[email-masked]</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'; 
    [email-masked]</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--

From: "Anders Rundgren" <[email-masked]>
To: "Guida, Richard [JJCUS]" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
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
Sender: [email-masked]

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' ; [email-masked]=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:  732 524 3785=20

  -----Original Message-----=20
  From: Anders Rundgren [mailto:[email-masked]]=20
  Sent: Wednesday, February 11, 2004 2:43 AM=20
  To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked]=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=[email-masked] =
href=3D"mailto:[email-masked]">Guida,=20
  Richard [JJCUS]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">'Anders Rundgren'</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">'Santosh=20
  Chokhani'</A> ; <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</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:[email-masked]">mailto:[email-masked]=
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
  [email-masked]</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--

From: "Anders Rundgren" <[email-masked]>
To: "Al Arsenault" <[email-masked]>
Cc: <[email-masked]>
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
Sender: [email-masked]

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

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, [email-masked]
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
Sender: [email-masked]

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

------_=_NextPart_001_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:  732 524 3785

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Wednesday, February 11, 2004 2:43 AM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked]
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:[email-masked]">mailto:[email-masked]=
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'; =
[email-masked]</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--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
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
Importance: Normal
Sender: [email-masked]

Anders:

You can do that now without changing 3280.

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]] 
Sent: Wednesday, February 11, 2004 2:43 AM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked]
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

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data inIE, IIS, Outlook)
Date: Wed, 11 Feb 2004 09:50:18 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, February 11, 2004 6:13 AM
To: [email-masked]; [email-masked]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data inIE,
IIS, Outlook)

"Santosh Chokhani" <[email-masked]> 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.

From: "Al Arsenault" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
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
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Anders Rundgren
> Sent: Wednesday, February 11, 2004 8:31 AM
> To: [email-masked]
> Cc: [email-masked]
> 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

Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Date: Wed, 11 Feb 2004 14:13:46 +0000
Sender: [email-masked]

--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__=[email-masked]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for &quot;Anders Rundgr=
en&quot; &lt;[email-masked]&gt;">&quot;Anders Rundgren&quot;=
 &lt;[email-masked]&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__=[email-masked]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4A4DFDF960E8f9e8a93df938690918c8FBBE4A4DFDF960E--

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

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

From: "Anders Rundgren" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, "Al Arsenault" <[email-masked]>, "David Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data inIE, IIS, Outlook)
Date: Wed, 11 Feb 2004 14:13:15 +0100
Sender: [email-masked]

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: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, February 11, 2004 12:12
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data inIE, IIS, Outlook)

"Anders Rundgren" <[email-masked]> 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).

Date: Thu, 12 Feb 2004 00:13:11 +1300
From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Sender: [email-masked]

"Santosh Chokhani" <[email-masked]> 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.

Date: Thu, 12 Feb 2004 00:12:39 +1300
From: [email-masked]
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Sender: [email-masked]

"Anders Rundgren" <[email-masked]> 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).

Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Date: Wed, 11 Feb 2004 10:04:24 +0000
Sender: [email-masked]

--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__=[email-masked]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for &quot;Anders Rundgr=
en&quot; &lt;[email-masked]&gt;">&quot;Anders Rundgren&quot;=
 &lt;[email-masked]&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__=[email-masked]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4A4DFA489948f9e8a93df938690918c8FBBE4A4DFA48994--

From: "Anders Rundgren" <[email-masked]>
To: "Guida, Richard [JJCUS]" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
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
Sender: [email-masked]

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

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
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
Sender: [email-masked]

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

------_=_NextPart_001_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:  732 524 3785

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Santosh Chokhani
Sent: Tuesday, February 10, 2004 2:11 PM
To: [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean Pawluk
Sent: Tuesday, February 10, 2004 6:42 AM
To: 'Lars Johansson'; 'Peter Gutmann'
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
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: [email-masked] [mailto:[email-masked]]On
Behalf Of Lars Johansson
Sent: Tuesday, February 10, 2004 3:53 AM
To: Peter Gutmann
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
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
[email-masked] | www.omegapoint.se
phone +46 70 915 88 40 | fax +46 8 545 106 93
Omegapoint AB

-------------------
>
> "Al Arsenault" <[email-masked]> 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: [email-masked]</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:[email-masked]">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: [email-masked]</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: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">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: [email-masked]; [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>[email-masked]</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: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">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: [email-masked]; [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>[email-masked]</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>[email-masked] | =
www.omegapoint.se</FONT>
<BR><FONT SIZE=3D2>phone +46 70 915 88 40 | fax +46 8 545 106 93</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;[email-masked]&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--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Date: Tue, 10 Feb 2004 18:43:44 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, February 10, 2004 11:39 AM
To: Peter Hesse
Cc: 'Masaki SHIMAOKA'; [email-masked]
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

Date: Tue, 10 Feb 2004 11:38:55 -0500
To: "Peter Hesse" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: "'Masaki SHIMAOKA'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 10 Feb 2004 17:44:05 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Sender: [email-masked]

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.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
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
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean Pawluk
Sent: Tuesday, February 10, 2004 6:42 AM
To: 'Lars Johansson'; 'Peter Gutmann'
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
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: [email-masked] [mailto:[email-masked]]On
Behalf Of Lars Johansson
Sent: Tuesday, February 10, 2004 3:53 AM
To: Peter Gutmann
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
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
[email-masked] | www.omegapoint.se
phone +46 70 915 88 40 | fax +46 8 545 106 93
Omegapoint AB

-------------------
>
> "Al Arsenault" <[email-masked]> 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.

From: "Anders Rundgren" <[email-masked]>
To: "Lars Johansson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
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
Sender: [email-masked]

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" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
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
[email-masked] | www.omegapoint.se
phone +46 70 915 88 40 | fax +46 8 545 106 93
Omegapoint AB

-------------------
>
> "Al Arsenault" <[email-masked]> 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.

From: "Jean Pawluk" <[email-masked]>
To: "'Lars Johansson'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
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
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Lars Johansson
Sent: Tuesday, February 10, 2004 3:53 AM
To: Peter Gutmann
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
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
[email-masked] | www.omegapoint.se
phone +46 70 915 88 40 | fax +46 8 545 106 93
Omegapoint AB

-------------------
>
> "Al Arsenault" <[email-masked]> 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.

From: Lars Johansson <[email-masked]>
Subject: RE: Policy User Interfaces =?us-ascii?q?=28was?= RE: Setting X.509 Policy Data in IE, IIS, =?us-ascii?q?Outlook=29?=
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: Peter Gutmann  <[email-masked]>
Date: Tue, 10 Feb 2004 10:53:03 +0100
Sender: [email-masked]

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
[email-masked] | www.omegapoint.se
phone +46 70 915 88 40 | fax +46 8 545 106 93
Omegapoint AB

-------------------
> 
> "Al Arsenault" <[email-masked]> 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.

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Peter Gutmann" <[email-masked]>
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
Sender: [email-masked]

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

Date: Fri, 6 Feb 2004 03:17:32 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Sender: [email-masked]

"Al Arsenault" <[email-masked]> 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.

Date: Mon, 9 Feb 2004 13:54:35 -0600
To: [email-masked], [email-masked]
Subject: Paper on Proxy Certificates
From: Von Welch <[email-masked]>
Reply-To: Von Welch <[email-masked]>
Sender: [email-masked]

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

Content-return: prohibited
Date: Mon, 09 Feb 2004 09:16:25 -0500
From: "Joel S. Kazin" <[email-masked]>
Subject: Re: question on RFC 3647
To: "Merkle, Johannes" <[email-masked]>, [email-masked]
Sender: [email-masked]

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  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: question on RFC 3647
Date: Mon, 9 Feb 2004 07:47:02 -0500
Importance: Normal
Sender: [email-masked]

Johannes:

I agree with you that they are redundant.  We missed removing 6.2.11

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Merkle, Johannes
Sent: Monday, February 09, 2004 4:41 AM
To: [email-masked]
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

To: [email-masked], [email-masked], [email-masked]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
From: [email-masked] (Peter Gutmann)
Date: Mon,  9 Feb 2004 12:43:11 +0100 (CET)
Sender: [email-masked]

"Al Arsenault" <[email-masked]> 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.

content-class: urn:content-classes:message
Subject: question on RFC 3647
Date: Mon, 9 Feb 2004 10:40:56 +0100
From: "Merkle, Johannes" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

Date: Sun, 08 Feb 2004 18:47:11 -0500
To: "Stefan Santesson" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: UTF-8 encoding after December 31 2003
Cc: [email-masked]
Sender: [email-masked]

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 

Date: Fri, 06 Feb 2004 19:43:30 +0000
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
CC: Wahaj <[email-masked]>
Subject: Re: What is 20 octets ?
Sender: [email-masked]

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: [email-masked], PGP key: via homepage.

Date: Fri, 06 Feb 2004 13:42:25 -0500
To: "Wahaj" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: What is 20 octets ?
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
Subject: Re: What is 20 octets ?
From: "Frank Balluffi" <[email-masked]>
Date: Fri, 6 Feb 2004 12:06:49 -0500
Sender: [email-masked]

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" <[email-masked]>
Sent by: [email-masked]
02/06/2004 10:39 AM

        To:     <[email-masked]>
        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;[email-masked]&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</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;[email-masked]&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_=--

Date: Fri, 6 Feb 2004 11:39:10 -0500 (EST)
From: Jack Lloyd <[email-masked]>
To: Wahaj <[email-masked]>
Cc: [email-masked]
Subject: Re: What is 20 octets ?
Sender: [email-masked]

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
> 

From: "Wahaj" <[email-masked]>
To: <[email-masked]>
Subject: What is 20 octets ?
Date: Fri, 6 Feb 2004 20:39:01 +0500
Sender: [email-masked]

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"

------=_NextPart_000_0007_01C3ECF1.41105A10--

Date: Fri, 06 Feb 2004 17:31:01 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: "Peter Hesse" <[email-masked]>
Subject: Re[2]: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: <[email-masked]>, [email-masked]
Sender: [email-masked]

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: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Olle Mulmo" <[email-masked]>
Subject: Re: Adding Metadata to PKI = ERROR?
Date: Fri, 6 Feb 2004 08:57:55 +0100
Sender: [email-masked]

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

From: "Olle Mulmo" <[email-masked]>
To: <[email-masked]>, "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>, "Richard Levitte - VMS Whacker" <[email-masked]>
Subject: RE: Adding Metadata to PKI = ERROR?
Date: Fri, 6 Feb 2004 08:12:24 +0100
Importance: Normal
Sender: [email-masked]

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: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Thursday, February 05, 2004 14:29
To: Anders Rundgren
Cc: [email-masked]; 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=

Date: Fri, 06 Feb 2004 16:04:44 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: Kiyoshi Watanabe <[email-masked]>
Subject: Re[2]: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

Subject: Re: Adding Metadata to PKI = ERROR?
To: "Anders Rundgren" <[email-masked]>
Cc: [email-masked], "Richard Levitte - VMS Whacker" <[email-masked]>
From: [email-masked]
Date: Thu, 5 Feb 2004 13:29:16 +0000
Sender: [email-masked]

--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__=[email-masked]" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for &quot;Anders Rundgr=
en&quot; &lt;[email-masked]&gt;">&quot;Anders Rundgren&quot;=
 &lt;[email-masked]&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__=[email-masked]>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=8FBBE4A2DFDA420F8f9e8a93df938690918c8FBBE4A2DFDA420F--

Date: Thu, 05 Feb 2004 13:29:26 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Adding Metadata to PKI = ERROR?
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

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" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Anders Rundgren" <[email-masked]>
To: "Richard Levitte - VMS Whacker" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Adding Metadata to PKI = ERROR?
Date: Thu, 5 Feb 2004 12:15:51 +0100
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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" <[email-masked]>
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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Content-class: urn:content-classes:message
Subject: RE: UTF-8 encoding after December 31 2003
Date: Thu, 5 Feb 2004 11:12:32 -0000
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Tim Polk" <[email-masked]>, "Russ Housley" <[email-masked]>
Sender: [email-masked]

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

> Sent: den 3 februari 2004 19:00

> To: Stefan Santesson

> Cc: [email-masked]

> 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; [email-masked]';
[email-masked]'; [email-masked]'; '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: [email-masked] [mailto:[email-masked]]
On Behalf Of Deacon, Alex
Sent: den 3 februari 2004 00:36
To: Stefan Santesson; [email-masked]'; [email-masked]';
[email-masked]'; '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:[email-masked]]=20
	Sent: Friday, January 30, 2004 8:41 AM
	To: [email-masked]; [email-masked]; [email-masked]; 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: [email-masked]
[mailto:[email-masked]] On Behalf Of Jim Schaad
	Sent: den 26 januari 2004 21:32
	To: Stefan Santesson; [email-masked]
	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: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
		Sent: Monday, January 26, 2004 9:23 AM
		To: [email-masked]
		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:[email-masked]]<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: [email-masked]<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>; [email-masked]';
[email-masked]'; [email-masked]'; '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'>
[email-masked] [mailto:[email-masked]] =
<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">[email-masked]</st1:PersonName>';
[email-masked]'; [email-masked]'; '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:[email-masked]] <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">[email-masked]</st1:PersonName>;
[email-masked]; [email-masked]; 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'>
[email-masked] [mailto:[email-masked]] =
<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>; [email-masked]<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> =
[email-masked]
[mailto:[email-masked]] <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> [email-masked]<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--

Date: Thu, 05 Feb 2004 10:54:33 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Adding Metadata to PKI = ERROR?
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

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" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Adding Metadata to PKI = ERROR?
Date: Thu, 5 Feb 2004 08:41:01 +0100
Sender: [email-masked]

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

Date: Wed, 04 Feb 2004 07:06:18 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Sender: [email-masked]

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.

From: "Peter Hesse" <[email-masked]>
To: "'Masaki SHIMAOKA'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Revised I-D: Memorandum for multi-domain PKI Interoperability
Date: Tue, 3 Feb 2004 14:20:41 -0500
Sender: [email-masked]

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Monday, January 26, 2004 4:24 AM
To: Masaki SHIMAOKA
Cc: IETF-PKIX; [email-masked]
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: +81 422 91 8498 (ext.3605)
> Fax: +81 422 45 0536
> e-mail: [email-masked]
> 
> 

Date: Tue, 3 Feb 2004 13:00:18 -0500
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: UTF-8 encoding after December 31 2003
Cc: [email-masked]
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: "Al Arsenault" <[email-masked]>, "David P. Kemp" <[email-masked]>, <[email-masked]>
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
Sender: [email-masked]

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

From: "Al Arsenault" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, "David P. Kemp" <[email-masked]>, <[email-masked]>
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
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Anders Rundgren
> Sent: Tuesday, February 03, 2004 2:42 AM
> To: David P. Kemp; [email-masked]
> 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" <[email-masked]>
> To: <[email-masked]>
> 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" <[email-masked]> 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.
> >

From: "Al Arsenault" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
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
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Peter Gutmann
> Sent: Tuesday, February 03, 2004 12:51 AM
> To: [email-masked]; [email-masked]
> Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data
> in IE, IIS, Outlook)
>
>
>
> "David P. Kemp" <[email-masked]> 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?

Content-class: urn:content-classes:message
Subject: RE: UTF-8 encoding after December 31 2003
Date: Tue, 3 Feb 2004 10:40:06 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Deacon, Alex" <[email-masked]>, "Stefan Santesson" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Tim Polk" <[email-masked]>, "Russ Housley" <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Deacon, Alex
Sent: den 3 februari 2004 00:36
To: Stefan Santesson; [email-masked]'; [email-masked]';
[email-masked]'; '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:[email-masked]]=20
	Sent: Friday, January 30, 2004 8:41 AM
	To: [email-masked]; [email-masked]; [email-masked]; 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: [email-masked]
[mailto:[email-masked]] On Behalf Of Jim Schaad
	Sent: den 26 januari 2004 21:32
	To: Stefan Santesson; [email-masked]
	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: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
		Sent: Monday, January 26, 2004 9:23 AM
		To: [email-masked]
		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'> =
[email-masked]
[mailto:[email-masked]] <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">[email-masked]</st1:PersonName>';
[email-masked]'; [email-masked]'; '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:[email-masked]] <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">[email-masked]</st1:PersonName>;
[email-masked]; [email-masked]; 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'>
[email-masked] [mailto:[email-masked]] =
<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>; [email-masked]<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> =
[email-masked]
[mailto:[email-masked]] <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> [email-masked]<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--

From: "Anders Rundgren" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
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
Sender: [email-masked]

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

Date: Tue, 03 Feb 2004 14:52:25 +0900 (JST)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability
From: Kiyoshi Watanabe <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 3 Feb 2004 18:51:22 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Sender: [email-masked]

"David P. Kemp" <[email-masked]> 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.

From: "Deacon, Alex" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Tim Polk'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Subject: RE: UTF-8 encoding after December 31 2003
Date: Mon, 2 Feb 2004 15:35:58 -0800 
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]] 
Sent: Friday, January 30, 2004 8:41 AM
To: [email-masked]; [email-masked]; [email-masked]; 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: [email-masked] [mailto:[email-masked]] On
Behalf Of Jim Schaad
Sent: den 26 januari 2004 21:32
To: Stefan Santesson; [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Monday, January 26, 2004 9:23 AM
To: [email-masked]
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:[email-masked]] <BR><B>Sent:</B> Friday, January 30, 2004 8:41 
  AM<BR><B>To:</B> [email-masked]; [email-masked]; [email-masked]; 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"> 
  [email-masked] [mailto:[email-masked]] <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; 
  [email-masked]<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> 
    [email-masked] [mailto:[email-masked]] <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> [email-masked]<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--

Date: Mon, 02 Feb 2004 15:21:39 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Sender: [email-masked]

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

Subject: Re: Question on OCSP response....
From: "Kwok Lee" <[email-masked]>
To: Dr Stephen Henson <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Mon, 02 Feb 2004 13:23:14 -0500
Sender: [email-masked]

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

Date: Mon, 02 Feb 2004 18:02:16 +0000
From: Dr Stephen Henson <[email-masked]>
To: Kwok Lee <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Question on OCSP response....
Sender: [email-masked]

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: [email-masked], PGP key: via homepage.

Date: Mon, 2 Feb 2004 18:41:28 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Question on OCSP response....
Cc: [email-masked]
Sender: [email-masked]

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

Date: Mon, 02 Feb 2004 09:47:24 -0700
From: Bryan Pitcher <[email-masked]>
To: Kwok Lee <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Question on OCSP response....
Sender: [email-masked]

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
>

From: "Kwok Lee" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Question on OCSP response....
Date: Mon, 2 Feb 2004 10:57:20 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_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--

From: "Anders Rundgren" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Subject: Re: Solved:Last Call: 'Qualified Certificates Profile' to Proposed Standard
Date: Mon, 2 Feb 2004 10:11:28 +0100
Sender: [email-masked]

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

Date: Mon, 02 Feb 2004 17:56:12 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Subject: Re[2]: UTF-8 encoding after December 31 2003
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Tim Polk" <[email-masked]>, "Russ Housley" <[email-masked]>
Sender: [email-masked]

=== 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: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

Content-class: urn:content-classes:message
Subject: SV: Last Call: 'Qualified Certificates Profile' to Proposed Standard
Date: Sun, 1 Feb 2004 20:15:52 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Skickat: sö 2/1/2004 8:33
Till: Stefan Santesson; [email-masked]
Ä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: [email-masked] genom Anders Rundgren
Skickat: sö 2/1/2004 10:45
Till: Stefan Santesson; [email-masked]
Ä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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
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:[email-masked]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [email-masked]
Ä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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
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: [email-masked] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [email-masked]
Ä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

From: "Anders Rundgren" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Subject: Re: Last Call: 'Qualified Certificates Profile' to Proposed Standard
Date: Sun, 1 Feb 2004 20:33:07 +0100
Sender: [email-masked]

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: [email-masked] genom Anders Rundgren
Skickat: sö 2/1/2004 10:45
Till: Stefan Santesson; [email-masked]
Ä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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
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:[email-masked]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [email-masked]
Ä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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
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: [email-masked] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [email-masked]
Ä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

Content-class: urn:content-classes:message
Subject: SV: Last Call: 'Qualified Certificates Profile' to Proposed Standard
Date: Sun, 1 Feb 2004 17:58:23 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] genom Anders Rundgren
Skickat: sö 2/1/2004 10:45
Till: Stefan Santesson; [email-masked]
Ä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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
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:[email-masked]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [email-masked]
Ä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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
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: [email-masked] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [email-masked]
Ä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

From: "Anders Rundgren" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Subject: Re: Last Call: 'Qualified Certificates Profile' to Proposed Standard
Date: Sun, 1 Feb 2004 10:45:28 +0100
Sender: [email-masked]

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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
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:[email-masked]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [email-masked]
Ä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" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
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: [email-masked] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [email-masked]
Ä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