Subject: Status of domain-certs-01 and sip-eku-02

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jul 2008 10:08:16 -0500

Folks: Scott and I have just released new versions of
domain-certs (-01) and sip-eku (-02).

Regarding sip-eku, Paul Hoffman from the PKIX WG has advised
us that we should probably NOT use EKU to indicate that the party
associated with this public key is an authorized SIP proxy for
the domain named in the certificate.  Instead, it has been
suggested that it will be cleaner to use a actual extension that
goes into the "extensions" field at the end of TBSCertificate
sequence.

Scott and I will be meeting Paul and others from the PKIX WG
to sort this out during the DUB IETF.  The changes that result
from this will be minor from the editing point of view, so we
will expeditiously get a new version out as soon as we agree
to the semantics.

In the meantime, the new versions of the drafts can be obtained
from:

http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-01.txt
and
http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-02.txt

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Jul 2008 10:30:20 -0700

Removing the SIP list, but keeping the author on:

>goes into the "extensions" field at the end of TBSCertificate

A brief history here. The document is specifying "the semantics of 
the domain name that is the subject of this certificate is Foo, not 
Bar which is what you might have expected". They used an EKU because 
other people had used EKUs for things they thought were similar.

I pointed out that a KU describes a usage of the key, not a semantic 
for the subject. From a PKIX semantics standpoint, they way to talk 
about the semantics of the subject is with an extension.

 From 5280:
    The key usage extension defines the purpose (e.g., encipherment,
    signature, certificate signing) of the key contained in the
    certificate.

    The extensions defined for X.509 v3 certificates provide methods for
    associating additional attributes with users or public keys and for
    managing relationships between CAs.

Do folks in the WG agree with my assessment that the draft should be 
using an extension instead of an EKU?

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Jul 2008 12:06:47 -0400

Paul,

>>...

I think it is more appropriate to focus on the EKU text from 5280, 
vs. the KU text, since the proposal is to assign an EKU OID for this 
use of certs. Section 4.2.1.12 describes the EKU extension and gives 
examples. The examples include TLS server vs. client authentication, 
code signing, time stamping, and OCSP response signing.  These 
examples from 5280 illustrate using EKU to signal what type of entity 
holds the corresponding private key, and for what purpose that key is 
being used.

So, using an EKU to signal that the private key holder is a SIP proxy 
(e.g., vs. a SIP end entity) is clearly consistent with the examples 
cited in 5280. I think that using an EKU to signal that the DNS SAN 
in the cert is to be used to constrain the range of SIP IDs can be 
verified using the cert is not completely inappropriate either.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Jul 2008 12:04:08 -0700

At 12:06 PM -0400 7/15/08, Stephen Kent wrote:
>examples from 5280 illustrate using EKU to signal what type of 
>entity holds the corresponding private key, and for what purpose 
>that key is being used.

Fully agree. That's only part of what is in the draft in question, however.

>So, using an EKU to signal that the private key holder is a SIP 
>proxy (e.g., vs. a SIP end entity) is clearly consistent with the 
>examples cited in 5280.

Yep.

>I think that using an EKU to signal that the DNS SAN in the cert is 
>to be used to constrain the range of SIP IDs can be verified using 
>the cert is not completely inappropriate either.

Should we read "not completely inappropriate" as meaning "mostly 
inappropriate" or "only a little inappropriate" or ...?

You have not addressed the central problem with using an EKU, namely 
that there are semantics that have nothing to with key usage at all.

    Inclusion of this KeyPurposeId in a certificate indicates that any
    DNS Subject names in the certificate are intended to identify the
    holder as authoritative for a SIP service in the domain named by the
    subjectAltName values.

To me, that seems "mostly inappropriate", as in "doing so stretches 
the standardized semantics of EKUs further than the IETF has ever 
stretched them, but maybe we feel like seeing how far we can stretch 
them before the break". (Yes, I'm feeling a bit of gutmannese here.)

Where in the spectrum of inappropriate do others feel this proposal is?

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Jul 2008 21:04:17 +0100

> Where in the spectrum of inappropriate do others feel this proposal is?

Not sure myself yet. Clearly they want a bit somewhere to indicate that
the subject is a SIP proxy, so I'm wondering:

- What's the harm of using EKU?
- How would you recommend they include that info?

S.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Jul 2008 15:34:37 -0400

>inappropriate" or "only a little inappropriate" or ...?

I was thinking "only a little inappropriate," but I was way too 
ambiguous in my choice of words!  Using an EKU to indicate that the 
cert subject is a SIP proxy vs. SIP EE is very much consistent with 
the other examples we give in 5280.
Using EKU to indicate how to interpret the DNS SAN is not obviously 
consistent with the cited examples. However, when we started using 
the EKU to say what type of subject the cert refers to, I think we 
were pretty far away from the KU notion of saying how to use the key 
anyway.

I am suggesting that we should consider interpreting EKU broadly, 
allowing an application to use it to convey additional, 
application-specific semantics about the cert, so long as those 
semantics are not appropriately expressed via other extensions that 
we have already defined.  That's potentially better than defining 
yet another extension. However, I am not so thoroughly wedded to this 
view that I cannot be convinced otherwise.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Jul 2008 13:48:00 -0700

>- How would you recommend they include that info?

As I said before, that part of what they want is fine for EKU. To me, 
what seems beyond key usage (and even stretched key usage) is "and 
all the domain names listed use this name as their SIP server".

--Paul Hoffman, Director
--VPN Consortium

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 15 Jul 2008 16:11:28 -0500

Paul Hoffman wrote:
> what seems beyond key usage (and even stretched key usage) is "and all 
> the domain names listed use this name as their SIP server".

Paul: I am a bit doubtful on "and all the domain names listed use this
name as their SIP server."  To be sure, practically speaking, the text:

   Inclusion of this KeyPurposeId in a certificate indicates that any
   DNS subject names in the certificate are intended to identify the
   holder as authoritative for a SIP service in the domain named by the
   subjectAltName values.

implies that as long as a client sees a URI that it used to contact
a server (sip:example.com) as an identity in the SAN (which may well
contain other identities) of the certificate provided by the server,
it can be rest assured that it has reached an authoritative server.

In the reverse direction, if a server has a policy that it only
accepts connections from the domain example.edu, then the
presence of such an identity (sip:example.edu) in the SAN (which
may well contain other identities) implies that the server is
accepting a connection from a client who is authorized in its
domain.

Does this have the same semantics as quoted above (i.e., "and all ...
SIP server.")?

Thank you immensely in helping us sort this out.

Ciao.

- vijay

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 16 Jul 2008 14:27:13 +1000

Consider if the "Inclusion..." paragraph is rephrased as:

  A party that is authoritative for a SIP service in a domain
  should use a certificate with that domain in the subjectAltName
  extension.
  Inclusion of id-kp-sipDomain as an extended key usage indicates
  that a certificate is appropriate for authenticating SIP connections...

It practically has the same affect (when worded properly) but does not imply that EKU defines the semantics of SAN.

This EKU usage looks suitable enough to me.

James Manger

----------
Subject: Re: Status of domain-certs-01 and sip-eku-02

...

[http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-02.txt]

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 15 Jul 2008 21:26:06 -0700

Paul,

I may have fewer issues with this than you do.  I think that the man problem
I have is more the way the language is stated that what they are saying.

>From what I read from the document (first scan) I would make the following
statements:

1.  SAN contains a set of equivalent names for me.
2.  I am authoritative to be used to do ... whatever it is that they want it
to do

I think that the same thing would be said if you put id-kp-serverAuth in the
EKU and placed two different domains in the SAN.  

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: Monday, July 14, 2008 10:30 AM
> To: Vijay K. Gurbani
> Cc: [email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 16 Jul 2008 09:14:29 -0400

I also tend to agree with Steve Kent.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jim Schaad
Sent: Wednesday, July 16, 2008 12:26 AM
To: 'Paul Hoffman'; 'Vijay K. Gurbani'
Cc: [email-masked]
Subject: RE: Status of domain-certs-01 and sip-eku-02

Paul,

I may have fewer issues with this than you do.  I think that the man
problem
I have is more the way the language is stated that what they are saying.

statements:

1.  SAN contains a set of equivalent names for me.
2.  I am authoritative to be used to do ... whatever it is that they
want it
to do

I think that the same thing would be said if you put id-kp-serverAuth in
the
EKU and placed two different domains in the SAN.  

Jim

---

From: Tom Gindin <[email-masked]>
Date: Wed, 16 Jul 2008 19:16:10 -0400

I wonder whether the wording means anything different than "
Inclusion of this KeyPurposeId in a certificate indicates that the holder 
is considered authoritative for a SIP service", followed by "this holder 
is authoritative only for SIP services which reside in those domains named 
by the SubjectAltName values".  The first of these statements looks like a 
legitimate EKU, and the second is much like a true statement about 
certificates using id-kp-serverAuth ("this certificate is authoritative 
only for those servers named in the SubjectAltName values").
        If that fairly modest rewording makes this look like a valid EKU, 
then Steve's argument is valid and the usage isn't really inappropriate at 
all.  The second of my two statements makes more sense in section 4 of the 
draft (usage) than in  section 3 (EKU definition), so section 4 should 
state in part "the certificate MUST NOT be considered authoritative for 
any SIP domain identity whose domain portion does not match those named by 
the SubjectAltName values".  Is this statement just as applicable to 
certificates using serverAuth as to those using sipDomain?
        I realize that this is a lot like what Jim said earlier.

                Tom Gindin

Paul Hoffman <[email-masked]> 
Sent by: [email-masked]
07/15/2008 03:04 PM

To
Stephen Kent <[email-masked]>
cc
"Vijay K. Gurbani" <[email-masked]>, [email-masked]
Subject
Re: Status of domain-certs-01 and sip-eku-02

>entity holds the corresponding private key, and for what purpose 

Fully agree. That's only part of what is in the draft in question, 
however.

Yep.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Tim Moses" <[email-masked]>
Date: Tue, 22 Jul 2008 14:36:27 -0400

Colleagues - I wonder whether defining a SIP type-id for the SAN OtherName
option is an approach more faithful to the 5280 intent.  The EKU value
'id-kp-serverAuth' could still be included.  All the best.  Tim. 

Tim Moses
+1 613 270 3183

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Hoffman
Sent: Tuesday, July 15, 2008 3:04 PM
To: Stephen Kent
Cc: Vijay K. Gurbani; [email-masked]
Subject: Re: Status of domain-certs-01 and sip-eku-02

At 12:06 PM -0400 7/15/08, Stephen Kent wrote:
>I think it is more appropriate to focus on the EKU text from 5280, vs. 
>the KU text, since the proposal is to assign an EKU OID for this use of 
>certs. Section 4.2.1.12 describes the EKU extension and gives examples. 
>The examples include TLS server vs. client authentication, code 
>signing, time stamping, and OCSP response signing.  These examples from 
>5280 illustrate using EKU to signal what type of entity holds the 
>corresponding private key, and for what purpose that key is being used.

>cited in 5280.

Yep.

>I think that using an EKU to signal that the DNS SAN in the cert is to 
>be used to constrain the range of SIP IDs can be verified using the 
>cert is not completely inappropriate either.

You have not addressed the central problem with using an EKU, namely that
there are semantics that have nothing to with key usage at all.

To me, that seems "mostly inappropriate", as in "doing so stretches the
standardized semantics of EKUs further than the IETF has ever stretched
them, but maybe we feel like seeing how far we can stretch them before the
break". (Yes, I'm feeling a bit of gutmannese here.)

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Jul 2008 05:01:30 -0400

>'id-kp-serverAuth' could still be included.  All the best.  Tim.

Tim,

Which portion of the problem we're discussing would the SIP type-id address?

Steve

---

From: "Tim Moses" <[email-masked]>
Date: Tue, 29 Jul 2008 15:08:48 -0400

Hi Steve.  I was thinking that a new SAN type-id may be a suitable way of
indicating that the certificate's subject may not identify a namespace that
includes the name of the server (the authorized SIP Proxy) to which you are
directly connected, but rather one that includes the name of another server;
the one that vouches for the SIP proxy.

Syntactically, it's a URI, but semantically it's different from the usual
SAN URI option.

Just a thought.

All the best.  Tim.

Tim Moses
+1 613 270 3183

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 5:02 AM
To: Tim Moses
Cc: Paul Hoffman; Vijay K. Gurbani; [email-masked]
Subject: RE: Status of domain-certs-01 and sip-eku-02

At 2:36 PM -0400 7/22/08, Tim Moses wrote:
>Colleagues - I wonder whether defining a SIP type-id for the SAN 
>OtherName option is an approach more faithful to the 5280 intent.  The 
>EKU value 'id-kp-serverAuth' could still be included.  All the best.  Tim.
>
>Tim Moses

Tim,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Jul 2008 09:41:57 -0400

Tim,

I think the discussions on the PKIX list came to the conclusion that 
the EKU semantics for this SIP context are OK, i.e., they are not 
inconsistent with other EKUs we have published.  If SIP decides that 
it also wants to use a new type-id to further reinforce the notion, 
that's obviously OK too.

Steve

To: [email-masked]
Subject: Oxygen bottle damages Qantas aircraft
From:   Lennon <[email-masked]>
Date:   Sat, 2 Aug 2008 07:27:16 +0800

Hillary admits she was wrong
http://www.sapristiestudio.com/livestreaming.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From: <[email-masked]>
To: <[email-masked]>
Subject: FBI watching us
Date: Thu, 31 Jul 2008 16:57:37 +0200

Get Facebook's F.B.I. Files http://GoodNewsGames.com/

Date: Thu, 31 Jul 2008 10:17:08 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re; WGLC for draft-ietf-pkix-rfc4055-update-01.txt
Sender: [email-masked]

The interval for this WGLC has completed (a few days ago) and there 
were no more comments requiring changes, so this document has Wg 
approval and will be forwarded to the IESG in August.

Steve

Content-class: urn:content-classes:message
Subject: RE: Inhibit Any-Policy extension
Date: Thu, 31 Jul 2008 09:54:08 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Peter Hesse" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F314.E79040E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Russ,

=20

I do not recall the list having a discussion on this.

=20

Besides, I am not saying revise 5280.

=20

I am stating what is prudent and am providing the rationale for it.

=20

Technical accuracy is not a matter of consensus, no matter how big the
group is or who is in it.  It is a matter of sound logic.

=20

________________________________

From: Russ Housley [mailto:[email-masked]]=20
Sent: Thursday, July 31, 2008 9:50 AM
To: Santosh Chokhani; Peter Hesse; [email-masked]
Subject: RE: Inhibit Any-Policy extension

=20

Santosh:

I disagree.  Given that RFC 5280 (and RFC 3280 before that) had
consensus , I see no reason to revisit the discussion.

Russ

At 04:13 PM 7/30/2008, Santosh Chokhani wrote:

Russ,
=20
Making inhibit anyPolicy non-critical is desirable, RFC 5280
notwithstanding.
=20
Inhibit anyPolicy extension was added late to the policy related
extensions in X.509.  Many clients do not support it.  Making this
extension non-critical should let you have your cake and eat it to.
Below is the rationale.
=20
The clients that recognize the extension must enforce it regardless of
criticality.  These clients will securely process the extension.
=20
The clients that do not recognize the extension are also not likely to
recognize the special OID of anyPolicy that was created in conjunction
with it and hence not processing the extension will be a wash, skipCerts
> 0 notwithstanding, which most PKIs do not do.

________________________________

From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Russ Housley
Sent: Wednesday, July 30, 2008 5:45 AM
To: Peter Hesse; [email-masked]
Subject: Re: Inhibit Any-Policy extension
=20
I my opinion, RFC 5280 got it right.  If a CA includes this extension it
MUST be critical.  This setting will ensure that all relying parties
honor it.  This is not a setting that is appropriate for some relying
parties to honor and others not.

Russ

At 03:03 PM 7/29/2008, Peter Hesse wrote:

Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."
=20
X.509 says "This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA."
=20
We have found a case in which a certificate processing implementation
has rejected a certificate because it has a non-critical inhibit
anyPolicy.  This is most likely because of the wording in 3280 (This
extension MUST be critical).  The PKI policy authority made the decision
to mark this extension non-critical following X.509.  We will work on
getting the certificate processing implementation to be more forgiving,
but in the meantime it bring up this question: Why does RFC5280 differ
from X.509 on the criticality of this extension?  There is a pretty
significant difference between a "recommendation" and a "MUST".
=20
Thanks,
=20
--Peter
=20

________________________________

 Peter Hesse                       [email-masked]
 Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.
    Visit our relaunched website! http://geminisecurity.com
<http://geminisecurity.com/>=20

"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder
=20

------_=_NextPart_001_01C8F314.E79040E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-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]-->
<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:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Russ,<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 do not recall the list having a
discussion on this.<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'>Besides, I am not saying revise =
5280.<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 am stating what is prudent and am =
providing
the rationale for it.<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'>Technical accuracy is not a matter =
of
consensus, no matter how big the group is or who is in it. &nbsp;It is a =
matter of
sound logic.<o:p></o:p></span></font></p>

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span 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'> Russ =
Housley
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, July 31, =
2008 9:50
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Santosh Chokhani; =
Peter Hesse;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Inhibit =
Any-Policy
extension</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=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Santosh:<br>
<br>
I disagree.&nbsp; Given that RFC 5280 (and RFC 3280 before that) had =
consensus
, I see no reason to revisit the discussion.<br>
<br>
Russ<br>
<br>
At 04:13 PM 7/30/2008, Santosh Chokhani wrote:<br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>Russ,<br>
&nbsp;<br>
Making inhibit anyPolicy non-critical is desirable, RFC 5280 =
notwithstanding.<br>
&nbsp;<br>
Inhibit anyPolicy extension was added late to the policy related =
extensions in
X.509.&nbsp; Many clients do not support it.&nbsp; Making this extension
non-critical should let you have your cake and eat it to.&nbsp; Below is =
the
rationale.<br>
&nbsp;<br>
The clients that recognize the extension must enforce it regardless of
criticality.&nbsp; These clients will securely process the =
extension.<br>
&nbsp;<br>
The clients that do not recognize the extension are also not likely to
recognize the special OID of anyPolicy that was created in conjunction =
with it
and hence not processing the extension will be a wash, skipCerts &gt; 0
notwithstanding, which most PKIs do not do.<o:p></o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D2
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:navy'>

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

</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] [<a =
href=3D"mailto:[email-masked]"
eudora=3Dautourl> mailto:[email-masked]</a>] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Russ Housley<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July 30, =
2008
5:45 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Peter Hesse; =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Inhibit =
Any-Policy extension<br>
</span></font>&nbsp;<br>
I my opinion, RFC 5280 got it right.&nbsp; If a CA includes this =
extension it
MUST be critical.&nbsp; This setting will ensure that all relying =
parties honor
it.&nbsp; This is not a setting that is appropriate for some relying =
parties to
honor and others not.<br>
<br>
Russ<br>
<br>
At 03:03 PM 7/29/2008, Peter Hesse wrote:<br>
<br>
Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
&#8220;Conforming CAs MUST mark this extension as critical.&#8221;<br>
&nbsp;<br>
X.509 says &#8220;This extension may, at the option of the certificate =
issuer,
be either critical or non-critical. It is recommended that it be =
critical,
otherwise a certificate user may not correctly interpret the stipulation =
of the
issuing CA.&#8221;<br>
&nbsp;<br>
We have found a case in which a certificate processing implementation =
has
rejected a certificate because it has a non-critical inhibit =
anyPolicy.&nbsp;
This is most likely because of the wording in 3280 (This extension MUST =
be
critical).&nbsp; The PKI policy authority made the decision to mark this
extension non-critical following X.509.&nbsp; We will work on getting =
the
certificate processing implementation to be more forgiving, but in the =
meantime
it bring up this question: Why does RFC5280 differ from X.509 on the
criticality of this extension?&nbsp; There is a pretty significant =
difference
between a &#8220;recommendation&#8221; and a &#8220;MUST&#8221;.<br>
&nbsp;<br>
Thanks,<br>
&nbsp;<br>
--Peter<br>
&nbsp;<o:p></o:p></p>

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

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[email-masked]<br>
&nbsp;Phone: 703-378-5808 x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gemini =
Security
Solutions, Inc.<br>
&nbsp;&nbsp;&nbsp; Visit our relaunched website! <a
href=3D"http://geminisecurity.com/">http://geminisecurity.com</a><br>
<br>
<i><span style=3D'font-style:italic'>&quot;A good programmer is someone =
who
always looks both ways before<br>
&nbsp;crossing a one-way street.&quot; --Doug Linder<br>
</span></i>&nbsp;<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C8F314.E79040E0--

Date: Thu, 31 Jul 2008 09:50:01 -0400
To: "Santosh Chokhani" <[email-masked]>, "Peter Hesse" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Inhibit Any-Policy extension
Sender: [email-masked]

<html>
<body>
Santosh:<br><br>
I disagree.&nbsp; Given that RFC 5280 (and RFC 3280 before that) had
consensus , I see no reason to revisit the discussion.<br><br>
Russ<br><br>
At 04:13 PM 7/30/2008, Santosh Chokhani wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2 color="#000080">
Russ,<br>
&nbsp;<br>
Making inhibit anyPolicy non-critical is desirable, RFC 5280
notwithstanding.<br>
&nbsp;<br>
Inhibit anyPolicy extension was added late to the policy related
extensions in X.509.&nbsp; Many clients do not support it.&nbsp; Making
this extension non-critical should let you have your cake and eat it
to.&nbsp; Below is the rationale.<br>
&nbsp;<br>
The clients that recognize the extension must enforce it regardless of
criticality.&nbsp; These clients will securely process the
extension.<br>
&nbsp;<br>
The clients that do not recognize the extension are also not likely to
recognize the special OID of anyPolicy that was created in conjunction
with it and hence not processing the extension will be a wash, skipCerts
&gt; 0 notwithstanding, which most PKIs do not do.<br>
<hr>
<div align="center"></font></div>
<font face="Tahoma" size=2><b>From:</b> [email-masked]
[<a href="mailto:[email-masked]" eudora="autourl">
mailto:[email-masked]</a>] <b>On Behalf Of </b>Russ
Housley<br>
<b>Sent:</b> Wednesday, July 30, 2008 5:45 AM<br>
<b>To:</b> Peter Hesse; [email-masked]<br>
<b>Subject:</b> Re: Inhibit Any-Policy extension<br>
</font><font face="Times New Roman, Times">&nbsp;<br>
I my opinion, RFC 5280 got it right.&nbsp; If a CA includes this
extension it MUST be critical.&nbsp; This setting will ensure that all
relying parties honor it.&nbsp; This is not a setting that is appropriate
for some relying parties to honor and others not.<br><br>
Russ<br><br>
At 03:03 PM 7/29/2008, Peter Hesse wrote:<br><br>
Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
“Conforming CAs MUST mark this extension as critical.”<br>
&nbsp;<br>
X.509 says “This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA.”<br>
&nbsp;<br>
We have found a case in which a certificate processing implementation has
rejected a certificate because it has a non-critical inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 (This
extension MUST be critical).&nbsp; The PKI policy authority made the
decision to mark this extension non-critical following X.509.&nbsp; We
will work on getting the certificate processing implementation to be more
forgiving, but in the meantime it bring up this question: Why does
RFC5280 differ from X.509 on the criticality of this extension?&nbsp;
There is a pretty significant difference between a “recommendation” and a
“MUST”.<br>
&nbsp;<br>
Thanks,<br>
&nbsp;<br>
--Peter<br>
&nbsp;<br>
<hr>
<div align="center"></div>
&nbsp;Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[email-masked]<br>
&nbsp;Phone: 703-378-5808 x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gemini
Security Solutions, Inc.<br>
&nbsp;&nbsp;&nbsp; Visit our relaunched website!
<a href="http://geminisecurity.com/">http://geminisecurity.com</a><br><br>
<i>&quot;A good programmer is someone who always looks both ways
before<br>
&nbsp;crossing a one-way street.&quot; --Doug Linder<br>
</i>&nbsp;</font></blockquote></body>
</html>

Date: Thu, 31 Jul 2008 09:41:57 -0400
To: "Tim Moses" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Status of domain-certs-01 and sip-eku-02
Cc: "Paul Hoffman" <[email-masked]>, "Vijay K. Gurbani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Tim,

I think the discussions on the PKIX list came to the conclusion that 
the EKU semantics for this SIP context are OK, i.e., they are not 
inconsistent with other EKUs we have published.  If SIP decides that 
it also wants to use a new type-id to further reinforce the notion, 
that's obviously OK too.

Steve

To: [email-masked]
Subject: 5 more arrested from west Texas polygamist sect
From:   Kisner <[email-masked]>
Date:   Thu, 31 Jul 2008 12:35:39 +0200

Madonna admits to 12 different affairs
http://www.skyline-kino.de/showvideo.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From: "Anders Rundgren" <[email-masked]>
To: "Massimiliano Pala" <[email-masked]>, "Tom Gindin" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
Date: Thu, 31 Jul 2008 01:55:13 +0200
Sender: [email-masked]

I'm less concerned about details regarding this protocol than how to use the information it provides.
Security GUI have shown to be very difficult to design since they either [try to] hide the gory stuff or assumes a level of
education that isn't generally available.  I wouldn't be surprised if Microsoft with their CardSpace scheme will [eventually] make
two-factor authentication as easy to use as credit cards; it even looks like credit cards!

Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 30, 2008 11:10
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt

Hi Tom,

In section 2.1.1. only a brief descriptions we list only some of the reasons
for adopting a PRQP and it is not intended to be exhaustive. The argument
in 2.1.2. still holds, in the sense that currently there is no mapping in
the certificates between DNS domains and certificates - as you pointed out
there is no field that could carry such information.

I will probably need to add some more deep considerations in this section
thus listing the benefits coming from the usage of a dynamic protocol. The
intent of defining a protocol for PKI resource query that is transport
independent allows for more flexibility than using a specific service like
DNS. I would not say that the DNS is not secure enough - it could be possible
to distribute signed records via DNS; it can be difficult from a management
point of view: it is my opinion that integrating that type of support in
current DNS is harder and takes longer than defining a new protocol which
is easy and can be implemented really fast.

Last, but not least, at the last IETF my presentation on extending PRQP to
a Peer-to-peer environment that would allow the implementation of a real
service discovery system for PKIs strongly suggest that the overhead introduced
by the definition of a specific protocol is rewarded with a wide range of
possibilities for PKI management and would allow for better usability of PKIs.
See section A.2 of the I-D for more information.

These are just some of the reasons I can come up with. The current status
of the draft is, AFAIK, on experimental track just because of this: we need
to know if this protocol would allow for an efficient and interoperable
method for PKI resource discovery or not. So far the DNS has not provided
such a service, IMHO. Anyhow, I would encourage the usage of the DNS SRV
record to locate a local RQA (if available), though.

As I am going to explain in my presentation later today, we are moving
forward from this point of view as an RQA will be setup for all of the
CAs within the TACAR repository (http://www.tacar.org). When we will have
a deployed environment and, eventually, support for client applications
we will be able to evaluate more what the results are and if it will be
worth to move the I-D to standard track or not.

I will a concise version of these considerations to the 2.1.2 section of
the I-D in order to make it more clear why we propose the usage of PRQP
instead of DNS SRV records - although I do not want this section to become
too long.

Thanks for the comments and, if you have more, please let me know :D

Later,
Max

Tom Gindin wrote:
>         Max:
>
>         The DNS Name has to go into a specific extension to be used.  I
> don't think that putting a DNS Name into IssuerAltName means "look here
> for SRV records associated with PKI management", and its most common
> meaning in SubjectAltName is "expect to see this certificate when you
> connect to this DNS Name", but an AccessDescription could easily be
> assigned to mean that it's a pointer to SRV records.  There are General
> Names associated with AKI, CRL Distribution Point, and Name Constraint as
> well, but they clearly are not appropriate for such purposes.
>         An argument that "DNS is not the right mechanism for this, and
> it's worth a new protocol to avoid using DNS" is different than the one
> you made in the first version of your draft.  It looks to me like the
> argument against DNS usage would rely heavily on the perception that DNS
> isn't secure enough, especially for revocation information.  Is that
> really a strong enough reason to expect typical relying parties to
> implement a new client protocol?
>
>                 Tom Gindin

-- 

Best Regards,

Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

Content-class: urn:content-classes:message
Subject: RE: Inhibit Any-Policy extension
Date: Wed, 30 Jul 2008 16:13:37 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Peter Hesse" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F280.C0BEAB3C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Russ,

=20

Making inhibit anyPolicy non-critical is desirable, RFC 5280
notwithstanding.

=20

Inhibit anyPolicy extension was added late to the policy related
extensions in X.509.  Many clients do not support it.  Making this
extension non-critical should let you have your cake and eat it to.
Below is the rationale.

=20

The clients that recognize the extension must enforce it regardless of
criticality.  These clients will securely process the extension.

=20

The clients that do not recognize the extension are also not likely to
recognize the special OID of anyPolicy that was created in conjunction
with it and hence not processing the extension will be a wash, skipCerts
> 0 notwithstanding, which most PKIs do not do.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Wednesday, July 30, 2008 5:45 AM
To: Peter Hesse; [email-masked]
Subject: Re: Inhibit Any-Policy extension

=20

I my opinion, RFC 5280 got it right.  If a CA includes this extension it
MUST be critical.  This setting will ensure that all relying parties
honor it.  This is not a setting that is appropriate for some relying
parties to honor and others not.

Russ

At 03:03 PM 7/29/2008, Peter Hesse wrote:

Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."
=20
X.509 says "This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA."
=20
We have found a case in which a certificate processing implementation
has rejected a certificate because it has a non-critical inhibit
anyPolicy.  This is most likely because of the wording in 3280 (This
extension MUST be critical).  The PKI policy authority made the decision
to mark this extension non-critical following X.509.  We will work on
getting the certificate processing implementation to be more forgiving,
but in the meantime it bring up this question: Why does RFC5280 differ
from X.509 on the criticality of this extension?  There is a pretty
significant difference between a "recommendation" and a "MUST".
=20
Thanks,
=20
--Peter
=20

________________________________

 Peter Hesse                       [email-masked]
 Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.
    Visit our relaunched website! http://geminisecurity.com
<http://geminisecurity.com/>=20

"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder
=20

------_=_NextPart_001_01C8F280.C0BEAB3C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<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:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Russ,<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'>Making inhibit anyPolicy =
non-critical is
desirable, RFC 5280 notwithstanding.<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'>Inhibit anyPolicy extension was =
added late
to the policy related extensions in X.509.&nbsp; Many clients do not =
support it.&nbsp;
Making this extension non-critical should let you have your cake and eat =
it to.&nbsp;
Below is the rationale.<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'>The clients that recognize the =
extension
must enforce it regardless of criticality. &nbsp;These clients will =
securely
process the extension.<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'>The clients that do not recognize =
the
extension are also not likely to recognize the special OID of anyPolicy =
that
was created in conjunction with it and hence not processing the =
extension will
be a wash, skipCerts &gt; 0 notwithstanding, which most PKIs do not =
do.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span 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>Russ Housley<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July 30, =
2008
5:45 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Peter Hesse; =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Inhibit =
Any-Policy
extension</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=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>I my opinion, RFC 5280 got it right.&nbsp; If a CA includes this
extension it MUST be critical.&nbsp; This setting will ensure that all =
relying
parties honor it.&nbsp; This is not a setting that is appropriate for =
some
relying parties to honor and others not.<br>
<br>
Russ<br>
<br>
At 03:03 PM 7/29/2008, Peter Hesse wrote:<br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 =
says
&#8220;Conforming CAs MUST mark this extension as critical.&#8221;<br>
&nbsp;<br>
X.509 says &#8220;This extension may, at the option of the certificate =
issuer,
be either critical or non-critical. It is recommended that it be =
critical,
otherwise a certificate user may not correctly interpret the stipulation =
of the
issuing CA.&#8221;<br>
&nbsp;<br>
We have found a case in which a certificate processing implementation =
has
rejected a certificate because it has a non-critical inhibit =
anyPolicy.&nbsp;
This is most likely because of the wording in 3280 (This extension MUST =
be
critical).&nbsp; The PKI policy authority made the decision to mark this
extension non-critical following X.509.&nbsp; We will work on getting =
the
certificate processing implementation to be more forgiving, but in the =
meantime
it bring up this question: Why does RFC5280 differ from X.509 on the
criticality of this extension?&nbsp; There is a pretty significant =
difference
between a &#8220;recommendation&#8221; and a &#8220;MUST&#8221;.<br>
&nbsp;<br>
Thanks,<br>
&nbsp;<br>
--Peter<br>
&nbsp;<o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[email-masked]<br>
&nbsp;Phone: 703-378-5808 x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gemini =
Security
Solutions, Inc.<br>
&nbsp;&nbsp;&nbsp; Visit our relaunched website! <a
href=3D"http://geminisecurity.com/">http://geminisecurity.com</a><br>
<br>
<i><span style=3D'font-style:italic'>&quot;A good programmer is someone =
who
always looks both ways before<br>
&nbsp;crossing a one-way street.&quot; --Doug Linder<br>
</span></i>&nbsp;<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C8F280.C0BEAB3C--

Date: Wed, 30 Jul 2008 11:14:41 -0400
From: "David A. Cooper" <[email-masked]>
To: Peter Hesse <[email-masked]>
CC: [email-masked]
Subject: Re: Inhibit Any-Policy extension
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Peter,<br>
<br>
As was previously noted, the relying party should not be rejecting the
certificate simply because the extension is marked non-critical.<br>
<br>
As to your question of why does RFC 5280 differ from X.509, it is
because one is the base standard, which defines the extension, and the
other is a profile.&nbsp; The purpose of RFC 5280 is to profile X.509, not
simply reformat it as an RFC.<br>
<br>
X.509 does not mandate that any public key certificate extension be
marked critical.&nbsp; Each extension is either marked as always
non-critical or optionally critical. (X.509 does mandate that some CRL
extensions always be marked critical.)&nbsp; I believe that it was fully
expected by the authors of X.509 that profiles would mandate that some
of the extensions be marked critical.<br>
<br>
Dave<br>
<br>
Peter Hesse wrote:
<blockquote cite="mid:001701c8f1ad$c53ee9d0$4fbcbd70$@com" type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="Microsoft Word 12 (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]-->
  <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
  </style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
  <div class="Section1">
  <p class="MsoNormal">Regarding the Inhibit anyPolicy extension (id-ce
54), RFC 5280
says &#8220;Conforming CAs MUST mark this extension as critical.&#8221;<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">X.509 says &#8220;This extension may, at the option of
the
certificate issuer, be either critical or non-critical. It is
recommended that
it be critical, otherwise a certificate user may not correctly
interpret the
stipulation of the issuing CA.&#8221;<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">We have found a case in which a certificate
processing
implementation has rejected a certificate because it has a non-critical
inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 (This
extension MUST be critical).&nbsp; The PKI policy authority made the
decision
to mark this extension non-critical following X.509.&nbsp; We will work on
getting the certificate processing implementation to be more forgiving,
but in
the meantime it bring up this question: Why does RFC5280 differ from
X.509 on the
criticality of this extension?&nbsp; There is a pretty significant
difference
between a &#8220;recommendation&#8221; and a &#8220;MUST&#8221;.<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">Thanks,<o:p></o:p></p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
  <p class="MsoNormal">--Peter<o:p></o:p></p>
  </div>
</blockquote>
<br>
</body>
</html>

Date: Wed, 30 Jul 2008 13:35:33 +0200
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: Peter Hesse <[email-masked]>, [email-masked]
Subject: Re: Inhibit Any-Policy extension
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040704080305040007080206
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Russ Housley wrote:
> I my opinion, RFC 5280 got it right. If a CA includes this extension=20
> it MUST be critical. This setting will ensure that all relying parties =

> honor it. This is not a setting that is appropriate for some relying=20
> parties to honor and others not.
I agree.

But is it correct for a relying party that recognizes the extension to=20
look at the criticality at all:

   A
   certificate-using system MUST reject the certificate if it encounters
   a critical extension it does not recognize or a critical extension
   that contains information that it cannot process.  A non-critical
   extension MAY be ignored if it is not recognized, but MUST be
   processed if it is recognized.=20

>
> Russ
>
> At 03:03 PM 7/29/2008, Peter Hesse wrote:
>> Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says=20
>> =E2=80=9CConforming CAs MUST mark this extension as critical.=E2=80=9D=

>>
>> X.509 says =E2=80=9CThis extension may, at the option of the certifica=
te=20
>> issuer, be either critical or non-critical. It is recommended that it =

>> be critical, otherwise a certificate user may not correctly interpret =

>> the stipulation of the issuing CA.=E2=80=9D
>>
>> We have found a case in which a certificate processing implementation =

>> has rejected a certificate because it has a non-critical inhibit=20
>> anyPolicy. This is most likely because of the wording in 3280 (This=20
>> extension MUST be critical). The PKI policy authority made the=20
>> decision to mark this extension non-critical following X.509. We will =

>> work on getting the certificate processing implementation to be more=20
>> forgiving, but in the meantime it bring up this question: Why does=20
>> RFC5280 differ from X.509 on the criticality of this extension? There =

>> is a pretty significant difference between a =E2=80=9Crecommendation=E2=
=80=9D and a=20
>> =E2=80=9CMUST=E2=80=9D.
>>
>> Thanks,
>>
>> --Peter
>>
>> ----------------------------------------------------------------------=
--
>> Peter Hesse [email-masked]
>> Phone: 703-378-5808 x105 Gemini Security Solutions, Inc.
>> Visit our relaunched website! http://geminisecurity.com=20
>> <http://geminisecurity.com/>
>>
>> /"A good programmer is someone who always looks both ways before
>> crossing a one-way street." --Doug Linder
>> /=20

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

--------------ms040704080305040007080206--

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: FW: I-D ACTION:draft-turner-caclearanceconstraints-01.txt 
Date: Wed, 30 Jul 2008 11:12:45 +0100
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_007B_01C8F235.31CB3A90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I thought I'd draw your attention to this ID as we'll be discussing it at
the meeting. 

spt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, July 14, 2008 7:45 PM
To: [email-masked]
Subject: I-D ACTION:draft-turner-caclearanceconstraints-01.txt 

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

	Title		: Clearance and CA Clearance Constraints Certificate
Extensions
	Author(s)	: S. Turner, S. Chokhani
	Filename	: draft-turner-caclearanceconstraints-01.txt
	Pages		: 15
	Date		: 2008-7-14
	
This document defines the syntax and semantics for the Clearance and 
   the Certification Authority (CA) Clearance Constraints X.509 
   certificate extensions.  The Clearance certificate extension is used 
   to indicate the clearance held by the subject.  The CA Clearance 
   Constraints certificate extension values in a Trust Anchor (TA) and 

   the CAs in a certification path constrain the effective Clearance of 
   the subject of the last certificate in the certification path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-turner-caclearanceconstraints-01.t
xt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_000_007B_01C8F235.31CB3A90
Content-Type: Message/External-body;
	name="draft-turner-caclearanceconstraints-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-turner-caclearanceconstraints-01.txt"

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

------=_NextPart_000_007B_01C8F235.31CB3A90
Content-Type: text/plain;
	name="ATT01135.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT01135.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------=_NextPart_000_007B_01C8F235.31CB3A90--

From: PREST <[email-masked]>
To: [email-masked]
Subject: Qantas crash blamed on Boeing, fleets recalled
Date: Wed, 30 Jul 2008 18:03:40 +0800

--Boundary_(ID_ufgIrAOAYFSrw8zqTnCAGW)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Rupert Murdoch and wife robbed at gunpoint http://euclide.fr/default.html

--Boundary_(ID_ufgIrAOAYFSrw8zqTnCAGW)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Rupert Murdoch and wife robbed at gunpoint<div><a href="http://euclide.fr/default.html">http://euclide.fr/default.html</a></div></body></html>

--Boundary_(ID_ufgIrAOAYFSrw8zqTnCAGW)--

Date: Wed, 30 Jul 2008 05:44:44 -0400
To: "Peter Hesse" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Inhibit Any-Policy extension
Sender: [email-masked]

<html>
<body>
I my opinion, RFC 5280 got it right.&nbsp; If a CA includes this
extension it MUST be critical.&nbsp; This setting will ensure that all
relying parties honor it.&nbsp; This is not a setting that is appropriate
for some relying parties to honor and others not.<br><br>
Russ<br><br>
At 03:03 PM 7/29/2008, Peter Hesse wrote:<br>
<blockquote type=cite class=cite cite="">Regarding the Inhibit anyPolicy
extension (id-ce 54), RFC 5280 says “Conforming CAs MUST mark this
extension as critical.”<br>
&nbsp;<br>
X.509 says “This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA.”<br>
&nbsp;<br>
We have found a case in which a certificate processing implementation has
rejected a certificate because it has a non-critical inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 (This
extension MUST be critical).&nbsp; The PKI policy authority made the
decision to mark this extension non-critical following X.509.&nbsp; We
will work on getting the certificate processing implementation to be more
forgiving, but in the meantime it bring up this question: Why does
RFC5280 differ from X.509 on the criticality of this extension?&nbsp;
There is a pretty significant difference between a “recommendation” and a
“MUST”.<br>
&nbsp;<br>
Thanks,<br>
&nbsp;<br>
--Peter<br>
&nbsp;<br>
<hr>
&nbsp;Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[email-masked]<br>
&nbsp;Phone: 703-378-5808 x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gemini
Security Solutions, Inc.<br>
&nbsp;&nbsp;&nbsp; Visit our relaunched website!
<a href="http://geminisecurity.com/">http://geminisecurity.com</a><br><br>
<i>&quot;A good programmer is someone who always looks both ways
before<br>
&nbsp;crossing a one-way street.&quot; --Doug Linder<br>
</i>&nbsp;</blockquote></body>
</html>

Date: Wed, 30 Jul 2008 10:10:04 +0100
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: Tom Gindin <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010608070909020901010402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tom,

In section 2.1.1. only a brief descriptions we list only some of the reasons
for adopting a PRQP and it is not intended to be exhaustive. The argument
in 2.1.2. still holds, in the sense that currently there is no mapping in
the certificates between DNS domains and certificates - as you pointed out
there is no field that could carry such information.

I will probably need to add some more deep considerations in this section
thus listing the benefits coming from the usage of a dynamic protocol. The
intent of defining a protocol for PKI resource query that is transport
independent allows for more flexibility than using a specific service like
DNS. I would not say that the DNS is not secure enough - it could be possible
to distribute signed records via DNS; it can be difficult from a management
point of view: it is my opinion that integrating that type of support in
current DNS is harder and takes longer than defining a new protocol which
is easy and can be implemented really fast.

Last, but not least, at the last IETF my presentation on extending PRQP to
a Peer-to-peer environment that would allow the implementation of a real
service discovery system for PKIs strongly suggest that the overhead introduced
by the definition of a specific protocol is rewarded with a wide range of
possibilities for PKI management and would allow for better usability of PKIs.
See section A.2 of the I-D for more information.

These are just some of the reasons I can come up with. The current status
of the draft is, AFAIK, on experimental track just because of this: we need
to know if this protocol would allow for an efficient and interoperable
method for PKI resource discovery or not. So far the DNS has not provided
such a service, IMHO. Anyhow, I would encourage the usage of the DNS SRV
record to locate a local RQA (if available), though.

As I am going to explain in my presentation later today, we are moving
forward from this point of view as an RQA will be setup for all of the
CAs within the TACAR repository (http://www.tacar.org). When we will have
a deployed environment and, eventually, support for client applications
we will be able to evaluate more what the results are and if it will be
worth to move the I-D to standard track or not.

I will a concise version of these considerations to the 2.1.2 section of
the I-D in order to make it more clear why we propose the usage of PRQP
instead of DNS SRV records - although I do not want this section to become
too long.

Thanks for the comments and, if you have more, please let me know :D

Later,
Max

Tom Gindin wrote:
>         Max:
> 
>         The DNS Name has to go into a specific extension to be used.  I 
> don't think that putting a DNS Name into IssuerAltName means "look here 
> for SRV records associated with PKI management", and its most common 
> meaning in SubjectAltName is "expect to see this certificate when you 
> connect to this DNS Name", but an AccessDescription could easily be 
> assigned to mean that it's a pointer to SRV records.  There are General 
> Names associated with AKI, CRL Distribution Point, and Name Constraint as 
> well, but they clearly are not appropriate for such purposes.
>         An argument that "DNS is not the right mechanism for this, and 
> it's worth a new protocol to avoid using DNS" is different than the one 
> you made in the first version of your draft.  It looks to me like the 
> argument against DNS usage would rely heavily on the perception that DNS 
> isn't secure enough, especially for revocation information.  Is that 
> really a strong enough reason to expect typical relying parties to 
> implement a new client protocol?
> 
>                 Tom Gindin

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

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

--------------ms010608070909020901010402--

Date: Wed, 30 Jul 2008 10:56:11 +0200
From: Peter Sylvester <[email-masked]>
Cc: [email-masked]
Subject: critical extended keyusage in RFC 3161 
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms070306050008030100060607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

rfc 3161 requires in 2.3

   The
   corresponding certificate MUST contain only one instance of the
   extended key usage field extension as defined in [RFC2459] Section
   4.2.1.13 with KeyPurposeID having value:

   id-kp-timeStamping.  This extension MUST be critical.

Some TSA do not set this, and there exist relying party software that
rejects a certficat with a non critical extended keyusage.

Peter

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

--------------ms070306050008030100060607--

From: "Liaquat Khan" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Peter Hesse'" <[email-masked]>, <[email-masked]>
Subject: RE: Inhibit Any-Policy extension
Date: Wed, 30 Jul 2008 10:49:52 +0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0080_01C8F232.01B42950
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

We often come across such situations not only because of differences in
standards but also because CAs tend to do their own thing sometime with
regards to setting the criticality flag or not.  

I would go a step further, i.e. the safe conclusion for sake of
interoperability from a practical point of view is the following:

-          It should not be the job of RP applications to enforce
"criticality"

-          Instead RP applications should simply process the extensions they
recognise, if there is an extension which is not recognised and it is marked
critical then the RP application should not accept that certificate.  

Regards,

LK

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: 29 July 2008 23:56
To: Peter Hesse; [email-masked]
Subject: RE: Inhibit Any-Policy extension

Peter,

5280 processing rules recommend that relying party not enforce this
criticality.  I recommend that the relying party software in your situation
be modified to not check and enforce criticality.

See paragraph 3 of Section 6.1 of 5280 and I quote below:

"While the certificate and CRL profiles specified in Sections 4 and 5

   of this document specify values for certificate and CRL fields and

   extensions that are considered to be appropriate for the Internet

   PKI, the algorithm presented in this section is not limited to

   accepting certificates and CRLs that conform to these profiles.

   Therefore, the algorithm only includes checks to verify that the

   certification path is valid according to X.509 and does not include

   checks to verify that the certificates and CRLs conform to this

   profile.  While the algorithm could be extended to include checks for

   conformance to the profiles in Sections 4 and 5, this profile

   RECOMMENDS against including such checks."

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Hesse
Sent: Tuesday, July 29, 2008 3:03 PM
To: [email-masked]
Subject: Inhibit Any-Policy extension

Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."

X.509 says "This extension may, at the option of the certificate issuer, be
either critical or non-critical. It is recommended that it be critical,
otherwise a certificate user may not correctly interpret the stipulation of
the issuing CA."

We have found a case in which a certificate processing implementation has
rejected a certificate because it has a non-critical inhibit anyPolicy.
This is most likely because of the wording in 3280 (This extension MUST be
critical).  The PKI policy authority made the decision to mark this
extension non-critical following X.509.  We will work on getting the
certificate processing implementation to be more forgiving, but in the
meantime it bring up this question: Why does RFC5280 differ from X.509 on
the criticality of this extension?  There is a pretty significant difference
between a "recommendation" and a "MUST".

Thanks,

--Peter

  _____  

 Peter Hesse                       [email-masked]

 Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.

    Visit our relaunched website! http://geminisecurity.com
<http://geminisecurity.com/> 

"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder

------=_NextPart_000_0080_01C8F232.01B42950
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:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns0=3D"http://schemas.microsoft.com/office/2004/12/omml">

<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]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;}
@font-face
	{font-family:Consolas;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Calibri;
	color:#1F497D;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:2143494809;
	mso-list-type:hybrid;
	mso-list-template-ids:-1899968034 -1427873694 134807555 134807557 =
134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-GB 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'>We often come across such =
situations not
only because of differences in standards but also because CAs tend to do =
their
own thing sometime with regards to setting the criticality flag or not. =
&nbsp;<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 go a step further, i.e. the =
safe
conclusion for sake of interoperability from a practical point of view =
is the
following:<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 =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>-<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>It
should not be the job of RP applications to enforce =
&#8220;criticality&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>-<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Instead RP
applications should simply process the extensions they recognise, if =
there is
an extension which is not recognised and it is marked critical then the =
RP
application should not accept that certificate. =
&nbsp;<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'>Regards,<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'>LK<o:p></o:p></span></font></p>

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Tahoma;color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Santosh Chokhani<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 29 July 2008 =
23:56<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Peter Hesse; =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Inhibit =
Any-Policy
extension</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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 =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>5280 processing =
rules
recommend that relying party not enforce this criticality.&nbsp; I =
recommend
that the relying party software in your situation be modified to not =
check and
enforce criticality.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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 =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>See paragraph 3 =
of
Section 6.1 of 5280 and I quote below:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dnavy
face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>&#8220;</span></font><font size=3D2 color=3Dblack =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New";color:windowtext'>While
the certificate and CRL profiles specified in Sections 4 and =
5<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; of this document specify values for =
certificate
and CRL fields and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; extensions that are considered to be =
appropriate
for the Internet<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; PKI, the algorithm presented in this =
section is
not limited to<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; accepting certificates and CRLs that =
conform to
these profiles.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; Therefore, the algorithm only includes =
checks to
verify that the<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; certification path is valid according to =
X.509
and does not include<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; checks to verify that the certificates =
and CRLs
conform to this<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; profile.&nbsp; While the algorithm could =
be
extended to include checks for<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; conformance to the profiles in Sections 4 =
and 5,
this profile<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; RECOMMENDS against including such =
checks.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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 =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Tahoma;color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Peter Hesse<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, July 29, =
2008 3:03
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Inhibit =
Any-Policy
extension</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'>Regarding the Inhibit anyPolicy extension =
(id-ce 54),
RFC 5280 says &#8220;Conforming CAs MUST mark this extension as =
critical.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'>X.509 says &#8220;This extension may, at the =
option of
the certificate issuer, be either critical or non-critical. It is =
recommended
that it be critical, otherwise a certificate user may not correctly =
interpret
the stipulation of the issuing CA.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'>We have found a case in which a certificate =
processing
implementation has rejected a certificate because it has a non-critical =
inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 =
(This
extension MUST be critical).&nbsp; The PKI policy authority made the =
decision
to mark this extension non-critical following X.509.&nbsp; We will work =
on
getting the certificate processing implementation to be more forgiving, =
but in
the meantime it bring up this question: Why does RFC5280 differ from =
X.509 on
the criticality of this extension?&nbsp; There is a pretty significant
difference between a &#8220;recommendation&#8221; and a =
&#8220;MUST&#8221;.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'>--Peter<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<div>

<div>

<div>

<div>

<div class=3DMsoNormal><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New Roman"'>

<hr size=3D2 width=3D450 style=3D'width:337.5pt' align=3Dleft>

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

</div>

</div>

</div>

</div>

</div>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DConsolas><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span></font><font=
 size=3D2
color=3D"#3333cc" face=3DConsolas><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Consolas;color:#3333CC'>Peter =
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;</span></font><font size=3D2 face=3DConsolas><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Consolas'> </span></font><font =
size=3D2
color=3Dblue face=3DConsolas><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
Consolas;color:blue'>[email-masked]<o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DConsolas><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span></font><font=
 size=3D2
color=3D"#3333cc" face=3DConsolas><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Consolas;color:#3333CC'>Phone: 703-378-5808 =
x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Gemini
Security Solutions, Inc.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
color=3D"#cc3333"
face=3DConsolas><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Consolas;
color:#CC3333'>&nbsp;&nbsp;&nbsp;&nbsp;Visit our relaunched website! <a
href=3D"http://geminisecurity.com/">http://geminisecurity.com</a></span><=
/font><font
size=3D1 color=3Dteal face=3DConsolas><span lang=3DEN-US =
style=3D'font-size:5.0pt;
font-family:Consolas;color:teal'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><i><font size=3D2 color=3Dteal =
face=3DConsolas><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Consolas;color:teal;font-style:ital=
ic'>&quot;A
good programmer is someone who always looks both ways before<br>
&nbsp;crossing a one-way street.&quot; --Doug =
Linder</span></font></i><i><span
lang=3DEN-US style=3D'font-style:italic'><o:p></o:p></span></i></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DEN-US
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0080_01C8F232.01B42950--

To: Massimiliano Pala <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
From: Tom Gindin <[email-masked]>
Date: Tue, 29 Jul 2008 19:36:41 -0400
Sender: [email-masked]

        Max:

        The DNS Name has to go into a specific extension to be used.  I 
don't think that putting a DNS Name into IssuerAltName means "look here 
for SRV records associated with PKI management", and its most common 
meaning in SubjectAltName is "expect to see this certificate when you 
connect to this DNS Name", but an AccessDescription could easily be 
assigned to mean that it's a pointer to SRV records.  There are General 
Names associated with AKI, CRL Distribution Point, and Name Constraint as 
well, but they clearly are not appropriate for such purposes.
        An argument that "DNS is not the right mechanism for this, and 
it's worth a new protocol to avoid using DNS" is different than the one 
you made in the first version of your draft.  It looks to me like the 
argument against DNS usage would rely heavily on the perception that DNS 
isn't secure enough, especially for revocation information.  Is that 
really a strong enough reason to expect typical relying parties to 
implement a new client protocol?

                Tom Gindin

Massimiliano Pala <[email-masked]> 
07/29/2008 10:48 AM

To
Tom Gindin/Watson/IBM@IBMUS
cc
[email-masked]
Subject
Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt

Hi Tom,

I do not understand how this actually applies. The dnsName is just one 
type
of GeneralNames (if I do remember correctly), therefore considerations 
about
AIA and SIA are not actually affected.

I do, anyway, understand your point: can we add a reference in the 
certificate
so that we know which DNS domain we shall query for DNS SRV records 
related
to PKI resources ?

I considered this, and I do really think it is a viable solution. I do 
have
some personal concerns about using DNS for this purpose. I think DNS SRV
records work great for services provided within an organization (eg., 
within
a university .example.edu - I am not aware of anyone who is actually using
DNS SRV records on public DNSs) but having PKI managers to modify the DNS
servers can be painful in certain environments. Besides this, having a
separate service allows us to provide signed messages (both client and 
server)
with NONCE. Moreover, a service that is decoupled from DNS can be easier 
to
maintain, especially in a trusted-responder multi-CAs mode.

But if other people share your opinion, please let me know, so we can 
update
the document properly.

Later,
Max

Tom Gindin wrote:
>         Section 2.1 of this draft gives an overview of existing 
solutions 
> and their limitations.  It does not appear that any consideration was 
> given to adding a new AccessDescription (to the SIA and/or AIA 
extensions) 
> for SRV record access.  The argument against the use of SRV records 
given 
> in 2.1.2 is that there is not generally a fixed mapping between the 
> certificate and a DNS space, which does not apply to a DNSName within an 

> AIA or SIA extension.

From: Lynda <[email-masked]>
To: [email-masked]
Subject: a catalogue
Date: Tue, 29 Jul 2008 16:06:54 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C8F195.1E4727E0
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

conscious choices about the information they receive, they can
more computer sights coming on line and appearing throughout the
expressions.  For instance, if we were to look at a painting on a

------=_NextPart_000_000B_01C8F195.1E4727E0
Content-Type: text/html;
	charset="windows-1251"
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=3Dwindows-125=
1">
<META content=3D"MSHTML 6.00.2800.1409" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>are real there is no problem. We will never create V.R. so</DIV><BR>
<P><DIV>C A 6N A D/9AN &nbsp;&nbsp;&nbsp; P 4 3H A RM A 6CY </DIV></P>
<DIV>V/A \G _RA - $1.49 </DIV>
<DIV>C 0/ A L / S - $2.20</DIV>
<DIV>S4 O M A - $0.65</DIV>
<DIV>L E6 V / T R A - $3.66</DIV>
<DIV>FEMALE \V0/0A8G0R5A - $1.57</DIV>
<DIV>U 2 L T 3R A M - $1.37</DIV>
<DIV>165  Items on Sale Today.</DIV>
<P><DIV><A href=3D"http://geocities.com/cdecwhksf"><b><font size=3D4>More f=
or less</font></b></A></DIV></P>
<DIV>occur during summer rainstorms as when I was younger. People</DIV>

</BODY></HTML>

------=_NextPart_000_000B_01C8F195.1E4727E0--

Content-class: urn:content-classes:message
Subject: RE: Inhibit Any-Policy extension
Date: Tue, 29 Jul 2008 15:56:06 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Peter Hesse" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8F1B5.233BE235
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Peter,

=20

5280 processing rules recommend that relying party not enforce this
criticality.  I recommend that the relying party software in your
situation be modified to not check and enforce criticality.

=20

See paragraph 3 of Section 6.1 of 5280 and I quote below:

=20

"While the certificate and CRL profiles specified in Sections 4 and 5

   of this document specify values for certificate and CRL fields and

   extensions that are considered to be appropriate for the Internet

   PKI, the algorithm presented in this section is not limited to

   accepting certificates and CRLs that conform to these profiles.

   Therefore, the algorithm only includes checks to verify that the

   certification path is valid according to X.509 and does not include

   checks to verify that the certificates and CRLs conform to this

   profile.  While the algorithm could be extended to include checks for

   conformance to the profiles in Sections 4 and 5, this profile

   RECOMMENDS against including such checks."

=20

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Hesse
Sent: Tuesday, July 29, 2008 3:03 PM
To: [email-masked]
Subject: Inhibit Any-Policy extension

=20

Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."

=20

X.509 says "This extension may, at the option of the certificate issuer,
be either critical or non-critical. It is recommended that it be
critical, otherwise a certificate user may not correctly interpret the
stipulation of the issuing CA."

=20

We have found a case in which a certificate processing implementation
has rejected a certificate because it has a non-critical inhibit
anyPolicy.  This is most likely because of the wording in 3280 (This
extension MUST be critical).  The PKI policy authority made the decision
to mark this extension non-critical following X.509.  We will work on
getting the certificate processing implementation to be more forgiving,
but in the meantime it bring up this question: Why does RFC5280 differ
from X.509 on the criticality of this extension?  There is a pretty
significant difference between a "recommendation" and a "MUST".

=20

Thanks,

=20

--Peter

=20

________________________________

 Peter Hesse                       [email-masked]

 Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.

    Visit our relaunched website! http://geminisecurity.com
<http://geminisecurity.com/>=20

"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder

=20

------_=_NextPart_001_01C8F1B5.233BE235
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:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns2=3D"http://schemas.microsoft.com/office/2004/12/omml">

<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]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Calibri;
	color:#1F497D;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</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'>Peter,<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'>5280 processing rules recommend =
that
relying party not enforce this criticality.&nbsp; I recommend that the =
relying
party software in your situation be modified to not check and enforce
criticality.<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'>See paragraph 3 of Section 6.1 of =
5280 and
I quote below:<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 style=3D'text-autospace:none'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&#8220;</span></f=
ont><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:
"Courier New";color:windowtext'>While the certificate and CRL profiles
specified in Sections 4 and 5<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; of this document specify values for =
certificate
and CRL fields and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; extensions that are considered to be =
appropriate
for the Internet<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; PKI, the algorithm presented in this =
section is
not limited to<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; accepting certificates and CRLs that =
conform to
these profiles.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; Therefore, the algorithm only includes =
checks to
verify that the<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; certification path is valid according to =
X.509
and does not include<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; checks to verify that the certificates =
and CRLs
conform to this<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; profile.&nbsp; While the algorithm could =
be
extended to include checks for<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; conformance to the profiles in Sections 4 =
and 5,
this profile<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
color:windowtext'>&nbsp;&nbsp; RECOMMENDS against including such =
checks.&#8221;<o:p></o:p></span></font></p>

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

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Peter Hesse<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, July 29, =
2008 3:03
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Inhibit =
Any-Policy
extension</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'>Regarding the Inhibit anyPolicy extension =
(id-ce 54),
RFC 5280 says &#8220;Conforming CAs MUST mark this extension as
critical.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'>X.509 says &#8220;This extension may, at the =
option of
the certificate issuer, be either critical or non-critical. It is =
recommended
that it be critical, otherwise a certificate user may not correctly =
interpret
the stipulation of the issuing CA.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'>We have found a case in which a certificate =
processing
implementation has rejected a certificate because it has a non-critical =
inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 =
(This
extension MUST be critical).&nbsp; The PKI policy authority made the =
decision
to mark this extension non-critical following X.509.&nbsp; We will work =
on
getting the certificate processing implementation to be more forgiving, =
but in
the meantime it bring up this question: Why does RFC5280 differ from =
X.509 on
the criticality of this extension?&nbsp; There is a pretty significant
difference between a &#8220;recommendation&#8221; and a =
&#8220;MUST&#8221;.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'>--Peter<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<div>

<div>

<div>

<div class=3DMsoNormal><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>

<hr size=3D2 width=3D450 style=3D'width:337.5pt' align=3Dleft>

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

</div>

</div>

</div>

</div>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DConsolas><span
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span></font><font=
 size=3D2
color=3D"#3333cc" face=3DConsolas><span =
style=3D'font-size:10.0pt;font-family:Consolas;
color:#3333CC'>Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;</span></font><font size=3D2 face=3DConsolas><span =
style=3D'font-size:
10.0pt;font-family:Consolas'> </span></font><font size=3D2 color=3Dblue
face=3DConsolas><span =
style=3D'font-size:10.0pt;font-family:Consolas;color:blue'>pmhesse@gemini=
security.com<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DConsolas><span
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span></font><font=
 size=3D2
color=3D"#3333cc" face=3DConsolas><span =
style=3D'font-size:10.0pt;font-family:Consolas;
color:#3333CC'>Phone: 703-378-5808 =
x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Gemini
Security Solutions, Inc.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
color=3D"#cc3333"
face=3DConsolas><span =
style=3D'font-size:10.0pt;font-family:Consolas;color:#CC3333'>&nbsp;&nbsp=
;&nbsp;&nbsp;Visit
our relaunched website! <a =
href=3D"http://geminisecurity.com/">http://geminisecurity.com</a></span><=
/font><font
size=3D1 color=3Dteal face=3DConsolas><span =
style=3D'font-size:5.0pt;font-family:Consolas;
color:teal'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><i><font size=3D2 color=3Dteal =
face=3DConsolas><span
style=3D'font-size:10.0pt;font-family:Consolas;color:teal;font-style:ital=
ic'>&quot;A
good programmer is someone who always looks both ways before<br>
&nbsp;crossing a one-way street.&quot; --Doug =
Linder</span></font><o:p></o:p></i></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C8F1B5.233BE235--

Date: Tue, 29 Jul 2008 16:27:30 -0300
From: Thenstedt <[email-masked]>
To: [email-masked]
Subject: Tropical storm watch issued for Florida

Shark attack off Australia, 2 dead http://www.kapitalmaster.com/default.html

Content-class: urn:content-classes:message
Subject: RE: Status of domain-certs-01 and sip-eku-02
Date: Tue, 29 Jul 2008 15:08:48 -0400
From: "Tim Moses" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "Paul Hoffman" <[email-masked]>, "Vijay K. Gurbani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0146_01C8F18D.006E98F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Just a thought.

All the best.  Tim.

Tim Moses
+1 613 270 3183

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 5:02 AM
To: Tim Moses
Cc: Paul Hoffman; Vijay K. Gurbani; [email-masked]
Subject: RE: Status of domain-certs-01 and sip-eku-02

Tim,

Steve

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

------=_NextPart_000_0146_01C8F18D.006E98F0--

From: "Peter Hesse" <[email-masked]>
To: <[email-masked]>
Subject: Inhibit Any-Policy extension
Date: Tue, 29 Jul 2008 15:03:16 -0400
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_0018_01C8F18C.3E2D49D0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Regarding the Inhibit anyPolicy extension (id-ce 54), RFC 5280 says
"Conforming CAs MUST mark this extension as critical."

X.509 says "This extension may, at the option of the certificate issuer, be
either critical or non-critical. It is recommended that it be critical,
otherwise a certificate user may not correctly interpret the stipulation of
the issuing CA."

We have found a case in which a certificate processing implementation has
rejected a certificate because it has a non-critical inhibit anyPolicy.
This is most likely because of the wording in 3280 (This extension MUST be
critical).  The PKI policy authority made the decision to mark this
extension non-critical following X.509.  We will work on getting the
certificate processing implementation to be more forgiving, but in the
meantime it bring up this question: Why does RFC5280 differ from X.509 on
the criticality of this extension?  There is a pretty significant difference
between a "recommendation" and a "MUST".

Thanks,

--Peter

  _____  

 Peter Hesse                       [email-masked]

 Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.

    Visit our relaunched website!  <http://geminisecurity.com/>
http://geminisecurity.com

"A good programmer is someone who always looks both ways before
 crossing a one-way street." --Doug Linder

------=_NextPart_000_0018_01C8F18C.3E2D49D0
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:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
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 12 (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]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal>Regarding the Inhibit anyPolicy extension (id-ce =
54), RFC 5280
says &#8220;Conforming CAs MUST mark this extension as =
critical.&#8221;<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>X.509 says &#8220;This extension may, at the option =
of the
certificate issuer, be either critical or non-critical. It is =
recommended that
it be critical, otherwise a certificate user may not correctly interpret =
the
stipulation of the issuing CA.&#8221;<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We have found a case in which a certificate =
processing
implementation has rejected a certificate because it has a non-critical =
inhibit
anyPolicy.&nbsp; This is most likely because of the wording in 3280 =
(This
extension MUST be critical).&nbsp; The PKI policy authority made the =
decision
to mark this extension non-critical following X.509.&nbsp; We will work =
on
getting the certificate processing implementation to be more forgiving, =
but in
the meantime it bring up this question: Why does RFC5280 differ from =
X.509 on the
criticality of this extension?&nbsp; There is a pretty significant =
difference
between a &#8220;recommendation&#8221; and a =
&#8220;MUST&#8221;.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>--Peter<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<div>

<div class=3DMsoNormal><span =
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>

<hr size=3D2 width=3D450 style=3D'width:337.5pt' align=3Dleft>

</span></div>

</div>

</div>

</div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span><span
style=3D'font-size:10.0pt;font-family:Consolas;color:#3333CC'>Peter
Hesse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;</span><span =
style=3D'font-size:10.0pt;font-family:Consolas'> </span><span
style=3D'font-size:10.0pt;font-family:Consolas;color:blue'>pmhesse@gemini=
security.com<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:Consolas'>&nbsp;</span><span
style=3D'font-size:10.0pt;font-family:Consolas;color:#3333CC'>Phone: =
703-378-5808
x105&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Gemini Security Solutions, =
Inc.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:Consolas;
color:#CC3333'>&nbsp;&nbsp;&nbsp;&nbsp;Visit our relaunched website! <a
href=3D"http://geminisecurity.com/"><span =
style=3D'color:blue'>http://geminisecurity.com</span></a></span><span
style=3D'font-size:10.0pt;font-family:Consolas;color:gray'><br>
<br>
</span><span =
style=3D'font-size:5.0pt;font-family:Consolas;color:teal'><o:p></o:p></sp=
an></p>

<p class=3DMsoNormal><i><span =
style=3D'font-size:10.0pt;font-family:Consolas;
color:teal'>&quot;A good programmer is someone who always looks both =
ways
before<br>
&nbsp;crossing a one-way street.&quot; --Doug =
Linder</span></i><i><o:p></o:p></i></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0018_01C8F18C.3E2D49D0--

Date: Tue, 29 Jul 2008 15:48:11 +0100
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: Tom Gindin <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090803030803000804010306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tom,

I do not understand how this actually applies. The dnsName is just one type
of GeneralNames (if I do remember correctly), therefore considerations about
AIA and SIA are not actually affected.

I do, anyway, understand your point: can we add a reference in the certificate
so that we know which DNS domain we shall query for DNS SRV records related
to PKI resources ?

I considered this, and I do really think it is a viable solution. I do have
some personal concerns about using DNS for this purpose. I think DNS SRV
records work great for services provided within an organization (eg., within
a university .example.edu - I am not aware of anyone who is actually using
DNS SRV records on public DNSs) but having PKI managers to modify the DNS
servers can be painful in certain environments. Besides this, having a
separate service allows us to provide signed messages (both client and server)
with NONCE. Moreover, a service that is decoupled from DNS can be easier to
maintain, especially in a trusted-responder multi-CAs mode.

But if other people share your opinion, please let me know, so we can update
the document properly.

Later,
Max

Tom Gindin wrote:
>         Section 2.1 of this draft gives an overview of existing solutions 
> and their limitations.  It does not appear that any consideration was 
> given to adding a new AccessDescription (to the SIA and/or AIA extensions) 
> for SRV record access.  The argument against the use of SRV records given 
> in 2.1.2 is that there is not generally a fixed mapping between the 
> certificate and a DNS space, which does not apply to a DNSName within an 
> AIA or SIA extension.

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

--------------ms090803030803000804010306--

To: [email-masked]
Subject: Obama denies wrongdoing in Presidential debate
From:   vu <[email-masked]>
Date:   Tue, 29 Jul 2008 20:23:13 +0800

Cats found eating human corpse
http://thelittles.fr/default.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

To: [email-masked]
Subject: Organ increase results proven in all subjects
From:   abate <[email-masked]>
Date:   Mon, 28 Jul 2008 23:22:14 +0200

I took a picture of her face in utter shock when she saw my size
http://www.talewill.com/

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Date: Mon, 28 Jul 2008 05:01:30 -0400
To: "Tim Moses" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Status of domain-certs-01 and sip-eku-02
Cc: "Paul Hoffman" <[email-masked]>, "Vijay K. Gurbani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Tim,

Steve

From: "TD Banknorth Business" <[email-masked]>
To: <[email-masked]>
Subject: Authorize Your TD Banknorth Business Account
Date: Sat, 26 Jul 2008  16:16:27 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C8EF3A.F51AB910
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0014_01C8EF3A.F51AB910"

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

   Dear TD Banknorth Treasury Management customer,

   Security and confidentiality are at the heart of the TD Banknorth.
   Your details (and your money) is protected by a number of
   technologies, including Secure Sockets Layer (SSL) encryption.
   We would like to notify you that TD Banknorth Commercial carries out
   customer details confirmation procedure that is compulsory for all TD
   Banknorth Commercial customers. This procedure is attributed to a
   routine banking software update.

   Please login to TD Banknorth Treasury Management using the link below
   and follow the instructions on the screen.

   http://webexpress5.tdbanknorth.com/wcmfd/wcmpw/CustomerVerify.htm?portal=3D25zdnoWjpzmWcskwzgdDzbkOhsa

   TD Banknorth Commercial Customer Service

------=_NextPart_001_0014_01C8EF3A.F51AB910
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.2900.2722" name=3DGENERATOR>
<title>TD Banknorth Treasury Management: User Verification Procedure</title>
<STYLE></STYLE>
</HEAD>
<body>
<p><span><img id=3D"u7447an38208" src=3D"cid:001201c8eeef$85332498$660aa8c0@user-4c33b33472"></span></p>
<p><font     face=3D"Arial, Helvetica, sans-serif">Dear   TD Banknorth Treasury Management   customer,</font></p>
<p><font     face=3D"Arial, Helvetica, sans-serif">Security      and      confidentiality      are   at   the   heart       of  the TD Banknorth.    Your    details   (and     your money)   is      protected     by    a   number     of     technologies,     including  Secure     Sockets    Layer      (SSL) encryption.<br>
We      would   like       to      notify you that       TD Banknorth Commercial    carries   out  customer       details      confirmation     procedure      that    is     compulsory    for  all       TD Banknorth Commercial    customers. This   procedure is     attributed  to    a   routine  banking      software    update.</font></p>
<p><font face=3D"Arial, Helvetica, sans-serif">Please     login   to  TD Banknorth Treasury Management     using     the link     below       and follow  the      instructions   on       the     screen.</font></p>
<p><u><span style=3D'color:blue'><font   face=3D"Arial, Helvetica, sans-serif"><a       href=3D"http://ww6.tdbanknorth.com.mode82.co.uk/wcmfd/wcmpw/CustomerVerify.htm?ssid=3D25zdnoWjpzmWcskwzgdDzbkOhsa">http://webexpress5.tdbanknorth.com/wcmfd/wcmpw/CustomerVerify.htm?portal=3D25zdnoWjpzmWcskwzgdDzbkOhsa</a></font></span></u></p>
<p><font face=3D"Arial, Helvetica, sans-serif">TD Banknorth Commercial Customer       Service</font></p>
</body>
</html>

------=_NextPart_001_0014_01C8EF3A.F51AB910--

------=_NextPart_000_0013_01C8EF3A.F51AB910
Content-Type: image/gif;
	name="ttl093.gif"
Content-Transfer-Encoding: base64
Content-ID: <001201c8eeef$85332498$660aa8c0@user-4c33b33472>

------=_NextPart_000_0013_01C8EF3A.F51AB910--

From: "Sharlene Gagne" <[email-masked]>
To: <[email-masked]>
Subject: syrinx 
Date: Sat, 26 Jul 2008 12:10:56 +0900

Symbo- GAGO
Global Agri-Med Technologies, Inc
Get in before they do, this is an easy doublerr
Symbo- GAGO
G l o b a l Agri - Med T e c h n o l og i e s, Inc
symbol GaG0

From: "Anders Rundgren" <[email-masked]>
To: "Kemp, David P." <[email-masked]>, <[email-masked]>
Subject: Re: generateCRMFrequest() Re: The PKC-only application security model ...
Date: Fri, 25 Jul 2008 21:03:23 +0200
Sender: [email-masked]

Hi Dave,
These are good questions which I will answer as well as I can.

Essentially any protocol can be augmented with additional data.
A problem with this particular case is that no standards organization
has AFAIK *ever* taken on a security-related standard with
browser bindings like Mozilla's generateCRMFrequest() or
Microsoft's CertEnroll. That KEYPROV is about
150 pages which gives a hint of how a complex NG-
provisioning PKI protocol could be.

Regarding the TPM trust indicator, there are a couple of
approaches that have one thing in common: the TPM device
has an embedded private key and certificate.  TPM 1.2
supports an incredibly elaborate and cryptographically
cool thing called DAA which even makes the connection
to the actual TPM device hidden.   Personally, I believe in
slightly less sophisticated solutions like embedding the
PoP signature in a TPM-signature.  This solution is not
100% malware proof (DAA is) but I don't find keeping
"secure" private keys exercisable by external PINs in
infected computers a particularly interesting object anyway.

Regards
Anders Rundgren

----- Original Message ----- 
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 25, 2008 18:03
Subject: RE: generateCRMFrequest() Re: The PKC-only application security model ...

The CRMF CertRequest contains a transaction id number, a certificate
template, and a list of control attributes.  RFC 4211 itself defines six
controls, and additional controls (such as requiring PIN activation for
use of the private key) can easily be defined.  However, unless there is
some sort of integrity mechanism between the CA and the token or TPM,
such signaling is useless - the user's workstation is a
man-in-the-middle that could easily say "sure, the private key is
protected on a TPM" and then go ahead and store it on a thumb drive.

Achieving a trusted path between the key storage device and the CA is
the challenge; including suitable signaling in a provisioning protocol
(CRMF, KEYPROV, or whatever) is a non-issue.  The certificate policies
extension has always been used by DoD to indicate (among other things)
whether the private key is stored in software, wimpy ("class 3")
hardware :-), or better ("class 4") hardware.  That extension is
meaningful only because the issuing workstations and token stock are
under control of the PKI, not the end user.

I'd be interested in learning how a CA can know that it is talking to an
actual "cheap, standardized, middleware-less" private key container, and
not someone pretending to be same.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Rundgren
Sent: Thursday, July 24, 2008 5:19 PM
To: Massimiliano Pala
Cc: [email-masked]; Scott Rea
Subject: generateCRMFrequest() Re: The PKC-only application security
model ...

Hi Max,

IMO it doesn't help if Mozilla fixes bugs in
generateCRMFrequest()
because it is inferior anyway.  Lets say an issuer wanted to
specify
that a user must assign a PIN-code following some kind of policy
there is no place for that in CRMF AFAIK.

If you look on a more recent effort like IETF's KEYPROV, it
indeed supports a set of useful of key add-ons.  Unfortunately
KEYPROV does neither support PKI, nor support browsers.

A glaring omission in the current crop of PKI provisioning
schemes is the ability indicating that the private key is
generated
and stored in a TPM or similar.  Due to this and similar
disconnects, 99% (or more) of the TPMs featured in
mid-to-high-end laptops are never activated.

Regards
Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; "Scott Rea" <[email-masked]>
Sent: Thursday, July 24, 2008 17:44
Subject: Re: The PKC-only application security model ...

Hi Anders, all,

I just want to point out that the generateCRMFrequest() is kinda
buggy
(at least it was some time ago...). Indeed I exchanged some
emails with
Jim Schaad and at the end we figured out that they are totally
mis-using
the CRMFRequest outside CMC.

Can anybody put us in contact with the people that are
developing that
part of the API in Mozilla/NSS so that we could try to fix the
current
mess they are doing ???

I would point out that one of the reason why PKIs have not got
further
(well, despite of what the common perception, PKIs are
definitely widely
used in many different environments...!!!) is tied to
*USABILITY*.

It is my belief that the usability problem and the difficulties
in
interacting with CAs are the real issues we should really try to
address
by promoting protocols that would take USABILITY in
consideration.

Another issue that I would like to draw the attention to is the
fact
that we are currently stuck with browsers to be the tool to
interact
with CAs. CMC & SCEP try to decouple the need to interact with
CAs by
using browsers. Historically browsers were the first
applications that
had support for PK Certificates, but now we are using PK in many
different environments, and the need for an easy way to interact
with
CAs is a real need, e.g. small devices, general applications,
or, even,
the very same Operating Systems.

Part of the work I am doing, i.e. the development of PRQP, is
actually
aimed to address these issues.

Later,
Max

Anders Rundgren wrote:
> *Other PKI Issues*
>
> IMHO, the reason why PKI hasn't got farther is because we
still lack a
> cheap and standardized "container" to keep private keys in,
that works
> in most computers without installation of proprietary
middleware.  I'm
> personally involved in solving this part of the
infrastructure.  Another
> issue is the unavailability of a standadized scheme for
on-line
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply
isn't good
> enough:  http://demo.webpki.org/mozkeygen

Date: Fri, 25 Jul 2008 12:56:04 -0400 (EDT)
From: Arshad Noor <[email-masked]>
To: ietf-pkix <[email-masked]>
Subject: Fwd: [ekmi] Public Review of SKSML v1.0
Sender: [email-masked]

FYI.

The OASIS EKMI Technical Committee would be grateful for any comments
received from members of this forum about the key-management protocol.

If you are interested in reviewing a working implementation of an early
version of this protocol, you can get the implementation here:

http://www.strongkey.org.  

This open-source implementation does not have all the features mentioned
in the specification, but has enough to give the reviewer an in-depth
view of its capabilities, strengths and weaknesses.

Thank you.

Arshad Noor
StrongAuth, Inc. 

----- Forwarded Message -----
From: "Mary McRae" <[email-masked]>
To: [email-masked], [email-masked]
Cc: "ekmi" <[email-masked]>
Sent: Thursday, July 24, 2008 7:04:49 PM (GMT-0800) America/Los_Angeles
Subject: [ekmi] Public Review of SKSML v1.0

To OASIS members, Public Announce Lists:

The OASIS Enterprise Key Management Infrastructure (EKMI) TC has recently
approved the following specification as a Committee Draft and approved the
package for public review:

Symmetric Key Services Markup Language (SKSML) Version 1.0

The public review starts today, 24 July 2008, and ends 23 September 2008. This
is an open invitation to comment. We strongly encourage feedback from potential
users, developers and others, whether OASIS members or not, for the sake of
improving the interoperability and quality of OASIS work. Please feel free to
distribute this announcement within your organization and to other appropriate
mail lists.

More non-normative information about the specification and the technical
committee may be found at the public home page of the TC at: 
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi. Comments may be
submitted to the TC by any person through the use of the OASIS TC Comment
Facility which can be located via the button marked "Send A Comment" at the top
of that page, or directly at: 
http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ekmi.

Submitted comments (for this work as well as other works of that TC) are
publicly archived and can be viewed at: 
http://lists.oasis-open.org/archives/ekmi-comment/. All comments submitted to
OASIS are subject to the OASIS Feedback License, which ensures that the feedback
you provide carries the same obligations at least as the obligations of the TC
members.

The specification document and related files are available here:

Editable Source (Authoritative):
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.odt 

PDF:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.pdf 

HTML:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.html 

Schema:
http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/schema/ 

Abstract:
This normative specification defines the first (1.0) version of the Symmetric
Key Services Markup Language (SKSML), an XML-based messaging protocol, by which
applications executing on computing devices may request and receive symmetric
key-management services from centralized key-management servers, securely, over
networks. Applications using SKSML are expected to either implement the SKSML
protocol, or use a software library - called the Symmetric Key Client Library
(SKCL) - that implements this protocol. SKSML messages are transported within a
SOAP layer, protected by a Web Services Security (WSS) header and can be used
over standard HTTP securely.

OASIS and the EKMI TC welcome your comments.

---------------------------------------------------
Mary P McRae
Manager of TC Administration, OASIS
email: [email-masked]  
web: www.oasis-open.org 

Content-class: urn:content-classes:message
Subject: RE: generateCRMFrequest() Re: The PKC-only application security model ...
Date: Fri, 25 Jul 2008 12:03:31 -0400
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

The CRMF CertRequest contains a transaction id number, a certificate
template, and a list of control attributes.  RFC 4211 itself defines six
controls, and additional controls (such as requiring PIN activation for
use of the private key) can easily be defined.  However, unless there is
some sort of integrity mechanism between the CA and the token or TPM,
such signaling is useless - the user's workstation is a
man-in-the-middle that could easily say "sure, the private key is
protected on a TPM" and then go ahead and store it on a thumb drive.

Achieving a trusted path between the key storage device and the CA is
the challenge; including suitable signaling in a provisioning protocol
(CRMF, KEYPROV, or whatever) is a non-issue.  The certificate policies
extension has always been used by DoD to indicate (among other things)
whether the private key is stored in software, wimpy ("class 3")
hardware :-), or better ("class 4") hardware.  That extension is
meaningful only because the issuing workstations and token stock are
under control of the PKI, not the end user.

I'd be interested in learning how a CA can know that it is talking to an
actual "cheap, standardized, middleware-less" private key container, and
not someone pretending to be same.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Rundgren
Sent: Thursday, July 24, 2008 5:19 PM
To: Massimiliano Pala
Cc: [email-masked]; Scott Rea
Subject: generateCRMFrequest() Re: The PKC-only application security
model ...

Hi Max,

IMO it doesn't help if Mozilla fixes bugs in
generateCRMFrequest()
because it is inferior anyway.  Lets say an issuer wanted to
specify
that a user must assign a PIN-code following some kind of policy
there is no place for that in CRMF AFAIK.

If you look on a more recent effort like IETF's KEYPROV, it
indeed supports a set of useful of key add-ons.  Unfortunately
KEYPROV does neither support PKI, nor support browsers.

A glaring omission in the current crop of PKI provisioning
schemes is the ability indicating that the private key is
generated
and stored in a TPM or similar.  Due to this and similar
disconnects, 99% (or more) of the TPMs featured in
mid-to-high-end laptops are never activated.

Regards
Anders Rundgren

----- Original Message -----=20
From: "Massimiliano Pala" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; "Scott Rea" <[email-masked]>
Sent: Thursday, July 24, 2008 17:44
Subject: Re: The PKC-only application security model ...

Hi Anders, all,

I just want to point out that the generateCRMFrequest() is kinda
buggy
(at least it was some time ago...). Indeed I exchanged some
emails with
Jim Schaad and at the end we figured out that they are totally
mis-using
the CRMFRequest outside CMC.

Can anybody put us in contact with the people that are
developing that
part of the API in Mozilla/NSS so that we could try to fix the
current
mess they are doing ???

I would point out that one of the reason why PKIs have not got
further
(well, despite of what the common perception, PKIs are
definitely widely
used in many different environments...!!!) is tied to
*USABILITY*.

It is my belief that the usability problem and the difficulties
in
interacting with CAs are the real issues we should really try to
address
by promoting protocols that would take USABILITY in
consideration.

Another issue that I would like to draw the attention to is the
fact
that we are currently stuck with browsers to be the tool to
interact
with CAs. CMC & SCEP try to decouple the need to interact with
CAs by
using browsers. Historically browsers were the first
applications that
had support for PK Certificates, but now we are using PK in many
different environments, and the need for an easy way to interact
with
CAs is a real need, e.g. small devices, general applications,
or, even,
the very same Operating Systems.

Part of the work I am doing, i.e. the development of PRQP, is
actually
aimed to address these issues.

Later,
Max

Anders Rundgren wrote:
> *Other PKI Issues*
>
> IMHO, the reason why PKI hasn't got farther is because we
still lack a
> cheap and standardized "container" to keep private keys in,
that works
> in most computers without installation of proprietary
middleware.  I'm
> personally involved in solving this part of the
infrastructure.  Another
> issue is the unavailability of a standadized scheme for
on-line
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply
isn't good
> enough:  http://demo.webpki.org/mozkeygen

From: Stefan Santesson <[email-masked]>
To: ietf-pkix <[email-masked]>
Date: Fri, 25 Jul 2008 13:15:55 +0100
Subject: Dublin agenda posted
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_9F11911AED01D24BAA1C2355723C3D32108A42AC13EAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The Dublin agenda is now posted and available from:
http://www.ietf.org/proceedings/08jul/agenda/pkix.txt

Please let me know if anything is wrong or missing.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

--_000_9F11911AED01D24BAA1C2355723C3D32108A42AC13EAEXMSGC332eu_
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-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.w3.org/TR/REC-html40" xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope=
/" xmlns:D=3D"DAV:" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas=
.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.or=
g/2001/04/xmlenc#" xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xm=
lns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http=
://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf=3D"http://schemas.micros=
oft.com/data/udc/xmlfile" xmlns:wf=3D"http://schemas.microsoft.com/sharepoi=
nt/soap/workflow/" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-c=
ompatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/o=
mml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relation=
ships" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/t=
ypes" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/me=
ssages" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"h=
ttp://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>The Dublin agenda is now posted and
available from:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"http://www.ietf.org/proceedings/08jul/agenda/pkix.txt">http://www.i=
etf.org/proceedings/08jul/agenda/pkix.txt</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Please let me know if anything is w=
rong or missing.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32108A42AC13EAEXMSGC332eu_--

From: Stefan Santesson <[email-masked]>
To: ietf-pkix <[email-masked]>
CC: Stephen Kent <[email-masked]>, Stephen Farrell <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 25 Jul 2008 12:03:18 +0100
Subject: RE: Comments on draft-ietf-pkix-tac-00.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I admit that I have some concerns with this I-D, but of reasons different f=
rom Denis.

What I'm asking myself is whether this I-D is an appropriate response to a =
real issue. Not the Internet privacy is not an issue, because it is. But as=
 a society of security engineers, we do have a history of over engineering =
security solutions ending up in no deployment, which we should take into co=
nsideration and hopefully learn from.

Sometimes then appropriate response to a threat is the easier to deploy and=
 easier to understand approach, providing reasonable security, rather than =
the complex fool proof solution.

Against this dual/blind signing architecture stands one where you simply le=
t a CA issue an anonymous certificate on its own and then trust that CA to =
keep your identity secret.
This would be very much like how PayPal keeps your credit card number from =
the merchant. They "could" give your details to the merchant, but they don'=
t. At least I trust them to not do that.

Such approach is of course a bit less secure, but is the simpler solution s=
ecure enough?
The problem we face as a standards group is that we don't necessarily know =
that, and we don't get to decide. In the end, this is decided by the market=
 players, the institutions and the governments on the play field.
All we can do is to offer them good solid specifications for what they want=
 to do.

Being adopted as a WG item does not guarantee that it will be published as =
an RFC, but given the effort put behind this work I do believe that we ough=
t to let this document be developed with the input of this WG. This process=
 has clearly already lead to improvements.

As this document describes a protocol under development aiming at being a f=
unctional standard, I do agree with Stephen Farrell that this should be exp=
erimental rather than Informational.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> On Behalf Of Stephen Kent
> Sent: den 7 juli 2008 18:30
> To: Stephen Farrell
> Cc: ietf-pkix
> Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
>
>
> At 4:52 PM +0100 7/7/08, Stephen Farrell wrote:
> >Stephen Kent wrote:
> >>>At this time, there is one response to this poll.
> >>
> >>no, there are two. I expressed my support for adopting the document
> >>as a PKIX work item.
> >
> >FWIW, (but without yet having given the I-D a proper read), I do
> >think that this topic is a good thing for PKIX to take on. The
> addition
> >of more privacy-friendly aspects to Internet protocols is a good thing.
> >
> >Based on a quick scan, I do have two preliminary comments:-
> >
> >1. This looks more like it ought end up as an experimental RFC (it
> >currently says informational). Not a big deal, but if anything at
> >all is meant to be experimental track, this'd be it IMO.
>
> fair comment. now that you mention it, experimental does seem more
> appropriate than informational.
>
> >2. I'd have a concern that regardless of the ability of the
> >protocol presented to help hide identities from PKI components,
> >lower layers (e.g. IP address logging) might leak identities.
> >I'm not sure how that would best be handled - at minimum as sec.
> >cons. text but if the protocol depends on a lack of logging then
> >its usefulness might be lessened so I'd be interested in knowing
> >whether the authors have already considered that or not (maybe
> >I missed it).
>
> good point and widely applicable to what the IETF considers to be
> privacy-preserving technologies. I agree that a discussion of these
> issues should be added to the security considerations section.
>
> >At some later stage, if this does progress, I'll give it a proper
> >read and might well have comments on other aspects of the scheme,
> >but overall, if PKIX is going to continue to do new work, then
> >this is just the right kind of thing to be doing.
>
> Thanks,
>
> Steve
>

From: "Anders Rundgren" <[email-masked]>
To: "Massimiliano Pala" <[email-masked]>
Cc: <[email-masked]>, "Scott Rea" <[email-masked]>
Subject: generateCRMFrequest() Re: The PKC-only application security model ...
Date: Thu, 24 Jul 2008 23:18:40 +0200
Sender: [email-masked]

Hi Max,

IMO it doesn't help if Mozilla fixes bugs in
generateCRMFrequest()
because it is inferior anyway.  Lets say an issuer wanted to
specify
that a user must assign a PIN-code following some kind of policy
there is no place for that in CRMF AFAIK.

If you look on a more recent effort like IETF's KEYPROV, it
indeed supports a set of useful of key add-ons.  Unfortunately
KEYPROV does neither support PKI, nor support browsers.

A glaring omission in the current crop of PKI provisioning
schemes is the ability indicating that the private key is
generated
and stored in a TPM or similar.  Due to this and similar
disconnects, 99% (or more) of the TPMs featured in
mid-to-high-end laptops are never activated.

Regards
Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; "Scott Rea" <[email-masked]>
Sent: Thursday, July 24, 2008 17:44
Subject: Re: The PKC-only application security model ...

Hi Anders, all,

I just want to point out that the generateCRMFrequest() is kinda
buggy
(at least it was some time ago...). Indeed I exchanged some
emails with
Jim Schaad and at the end we figured out that they are totally
mis-using
the CRMFRequest outside CMC.

Can anybody put us in contact with the people that are
developing that
part of the API in Mozilla/NSS so that we could try to fix the
current
mess they are doing ???

I would point out that one of the reason why PKIs have not got
further
(well, despite of what the common perception, PKIs are
definitely widely
used in many different environments...!!!) is tied to
*USABILITY*.

It is my belief that the usability problem and the difficulties
in
interacting with CAs are the real issues we should really try to
address
by promoting protocols that would take USABILITY in
consideration.

Another issue that I would like to draw the attention to is the
fact
that we are currently stuck with browsers to be the tool to
interact
with CAs. CMC & SCEP try to decouple the need to interact with
CAs by
using browsers. Historically browsers were the first
applications that
had support for PK Certificates, but now we are using PK in many
different environments, and the need for an easy way to interact
with
CAs is a real need, e.g. small devices, general applications,
or, even,
the very same Operating Systems.

Part of the work I am doing, i.e. the development of PRQP, is
actually
aimed to address these issues.

Later,
Max

Anders Rundgren wrote:
> *Other PKI Issues*
>
> IMHO, the reason why PKI hasn't got farther is because we
still lack a
> cheap and standardized "container" to keep private keys in,
that works
> in most computers without installation of proprietary
middleware.  I'm
> personally involved in solving this part of the
infrastructure.  Another
> issue is the unavailability of a standadized scheme for
on-line
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply
isn't good
> enough:  http://demo.webpki.org/mozkeygen

Date: Thu, 24 Jul 2008 14:15:33 -0400
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: "Miller, Timothy J." <[email-masked]>
CC: [email-masked]
Subject: Re: The PKC-only application security model ...
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090607020707030503030701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Timothy,

I find interesting that you think that the new Firefox 3 interface is
somewhat usable. I really think that they changed the original interface
to imitate IE behavior. In my experience, the new way to actually browse
an https website certified by a CA that is not part of the trust anchors
is totally unusable. The average response of the user is: this website
does not work. They really have no idea of what (and why should they?)
they have to do when this situation happens. The very same thing applies
to IE and their page with the red-shield "continue" option.

It is interesting that https connections to "untrusted" anchors are
treated with less trust than http connection. *WHY* ? Just to get more
money to have the trust anchors embedded into the applications ? In other
words: what makes an untrusted https connection more dangerous than an
untrusted http ?

This is just another example of how developers do not realize how complex
the trust management can be for the user, and the average level of awareness
about security. Presenting complex interfaces just to say that an https
connection is, indeed, at the same level of trust as an http connection
leaves the user with a frustrating experience (and distrust about security
in general).

Later,
Max

Miller, Timothy J. wrote:
> Yes, but when using self-signed certs clients are going to get nagged with
> trust warning dialogs until they set explicit trust on the server's cert.
> This goes back to the education issue.  Firefox 3's new trust ceremony
> implementation makes setting trust pretty simple to do though the number of
> clicks is a little high.  You may run afoul of policy restrictions with IE
> depending on strictness of domain security policy, but this won't affect
> home users.

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

--------------ms090607020707030503030701--

Date: Thu, 24 Jul 2008 20:14:24 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: The PKC-only application security model ...
Sender: [email-masked]

Massimiliano Pala wrote:
> [...]
> I just want to point out that the generateCRMFrequest() is kinda buggy
> (at least it was some time ago...). Indeed I exchanged some emails with
> Jim Schaad and at the end we figured out that they are totally mis-using
> the CRMFRequest outside CMC.
>
> Can anybody put us in contact with the people that are developing that
> part of the API in Mozilla/NSS so that we could try to fix the current
> mess they are doing ???
>[...]

You can use either the newsgroup
http://groups.google.com/group/mozilla.dev.tech.crypto/topics
or the mailing list
https://lists.mozilla.org/listinfo/dev-tech-crypto

Note that generateCRMFrequest is PSM code (the glue code between Fx and 
NSS) on which about nobody is working, but the part that formats the 
CRMF request is inside NSS, on which they are a number of Sun and Red 
Hat developpers working. If the problem is on the asn1 format, or 
support of the functionnalities they should listen.
Changes to the current format might require downward compatiblity or 
synchronisation with the Dogtag project, though :
http://pki.fedoraproject.org/wiki/PKI_Main_Page

Date: Thu, 24 Jul 2008 11:29:15 -0500
From: Thierry Moreau <[email-masked]>
To: "Miller, Timothy J." <[email-masked]>
CC:  [email-masked]
Subject: Re: The PKC-only application security model ...
Sender: [email-masked]

Miller, Timothy J. wrote:

> 
>>Can we do e-commerce applications (protected by a client key pair) in a
>>plain off-the-sheld browser based on the KCM trust model? I doubt, but
>>your educated input would be welcome.
> 
> 
> Yes, but when using self-signed certs clients are going to get nagged with
> trust warning dialogs until they set explicit trust on the server's cert.
> This goes back to the education issue.  Firefox 3's new trust ceremony
> implementation makes setting trust pretty simple to do though the number of
> clicks is a little high.  You may run afoul of policy restrictions with IE
> depending on strictness of domain security policy, but this won't affect
> home users.
> 

If the goal is to improve the education issue, may I respectfully 
suggest that the above deserves clarification.

In e-commerce applications, the client act as a relying party for the 
server, and the server acts as a relying party for the client (when 
protected by a client key pair). It is not clear to me in which role 
(relying party vs digital signatory) the client
a) gets nagged with trust warning dialog,
b) proceeds through the Firefox 3's new trust ceremony, and
c) runs afoul of policy restrictions with IE.

If the answer to a) b) and c) is "the cient as the relying party for the 
server's authentication", then it brings us to the very first role 
reversal identified in my reply: KCM in Firefox browser assists the user 
in her relying party role, while the PKC-only application security 
scheme cares about the user as a digital signatory.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

Content-class: urn:content-classes:message
Subject: RE: The PKC-only application security model ...
Date: Thu, 24 Jul 2008 11:50:09 -0400
From: "Miller, Timothy J." <[email-masked]>
To: "Thierry Moreau" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_0041_01C8ED7B.0AA33E90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

>If you refer to KCM for server site certificates, my document is the
>other way around, i.e. *client-side* public keys carried in meaningless
>security certificates. (I did notice the reversed similarity when doing
>the research.)

KCM applies on both sides.  SSH's RSA pubkey authentication method, for
example, is using KCM concepts even though it doesn't explicitly call it
such.

>The search engine result also pointed to KCM with S/MIME, perhaps as a
>trust model unlike PKI and unlike PGP web of trust. Quite honestly, I
>didn't review these search results.

You should read Garfinkle's "Johnny 2: A User Test of Key Continuity
Management with S/MIME and Outlook Express."

http://www.truststc.org/pubs/5.html

It's a good starting point on KCM concepts.  The follow his references for
more.  Citeseer is your friend, BTW:

http://citeseer.ist.psu.edu/

>Also don't forget that the idea behind my document is to leave protocols
>  and fielded implementations untouched - as far as I know, TLS (at
>least in the leading implementations) does not support client key pairs
>without an X.509 certificate.

Nothing stops you from generating a self-signed cert to transport keys via
protocols that expect X.509.  Your back-end logic need not apply X.509 trust
and validation rules, however.

Remember that the key to KCM is educating participants on how it works and
what to expect.  The Johnny 2 paper backs that up, IMHO, though the point
Simson and others are trying to make is that KCM is a more intuitive model
for otherwise uninitiated users, and thus easier to use than either
hierarchical or web of trust models.

Until we have an installed base of applications using explicit KCM models
the jury will probably remain out on the subject.  Personally I think they
have a point but the industry has gone a different way and usability issues
are a small rudder on a big ship.

>Can we do e-commerce applications (protected by a client key pair) in a
>plain off-the-sheld browser based on the KCM trust model? I doubt, but
>your educated input would be welcome.

Yes, but when using self-signed certs clients are going to get nagged with
trust warning dialogs until they set explicit trust on the server's cert.
This goes back to the education issue.  Firefox 3's new trust ceremony
implementation makes setting trust pretty simple to do though the number of
clicks is a little high.  You may run afoul of policy restrictions with IE
depending on strictness of domain security policy, but this won't affect
home users.

-- Tim

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

------=_NextPart_000_0041_01C8ED7B.0AA33E90--

Date: Thu, 24 Jul 2008 11:44:40 -0400
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: Anders Rundgren <[email-masked]>
CC: [email-masked], Scott Rea <[email-masked]>
Subject: Re: The PKC-only application security model ...
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060805010207020308000100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Anders, all,

I just want to point out that the generateCRMFrequest() is kinda buggy
(at least it was some time ago...). Indeed I exchanged some emails with
Jim Schaad and at the end we figured out that they are totally mis-using
the CRMFRequest outside CMC.

Can anybody put us in contact with the people that are developing that
part of the API in Mozilla/NSS so that we could try to fix the current
mess they are doing ???

I would point out that one of the reason why PKIs have not got further
(well, despite of what the common perception, PKIs are definitely widely
used in many different environments...!!!) is tied to *USABILITY*.

It is my belief that the usability problem and the difficulties in
interacting with CAs are the real issues we should really try to address
by promoting protocols that would take USABILITY in consideration.

Another issue that I would like to draw the attention to is the fact
that we are currently stuck with browsers to be the tool to interact
with CAs. CMC & SCEP try to decouple the need to interact with CAs by
using browsers. Historically browsers were the first applications that
had support for PK Certificates, but now we are using PK in many
different environments, and the need for an easy way to interact with
CAs is a real need, e.g. small devices, general applications, or, even,
the very same Operating Systems.

Part of the work I am doing, i.e. the development of PRQP, is actually
aimed to address these issues.

Later,
Max

Anders Rundgren wrote:
> *Other PKI Issues*
>  
> IMHO, the reason why PKI hasn't got farther is because we still lack a 
> cheap and standardized "container" to keep private keys in, that works 
> in most computers without installation of proprietary middleware.  I'm 
> personally involved in solving this part of the infrastructure.  Another 
> issue is the unavailability of a standadized scheme for on-line 
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply isn't good 
> enough:  http://demo.webpki.org/mozkeygen

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

--------------ms060805010207020308000100--

Date: Thu, 24 Jul 2008 10:34:18 -0500
From: Thierry Moreau <[email-masked]>
To: "Miller, Timothy J." <[email-masked]>
CC:  [email-masked]
Subject: Re: The PKC-only application security model ...
Sender: [email-masked]

Miller, Timothy J. wrote:

> The phrase you're looking for is "Key Continuity Management," which will net
> you a lot of research and deployed systems using it as a trust technique.
> If that's your route you really don't need to shoehorn it into an X.509
> structure.

OK, I ran a search engine on this.

If you refer to KCM for server site certificates, my document is the 
other way around, i.e. *client-side* public keys carried in meaningless 
security certificates. (I did notice the reversed similarity when doing 
the research.)

The search engine result also pointed to KCM with S/MIME, perhaps as a 
trust model unlike PKI and unlike PGP web of trust. Quite honestly, I 
didn't review these search results.

Also don't forget that the idea behind my document is to leave protocols 
  and fielded implementations untouched - as far as I know, TLS (at 
least in the leading implementations) does not support client key pairs 
without an X.509 certificate.

Can we do e-commerce applications (protected by a client key pair) in a 
plain off-the-sheld browser based on the KCM trust model? I doubt, but 
your educated input would be welcome.

Thanks for the feedback,

-- 

- Thierry Moreau

Date: Thu, 24 Jul 2008 10:08:39 -0500
From: Thierry Moreau <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC:  [email-masked]
Subject: Re: The PKC-only application security model ...
Sender: [email-masked]

Anders Rundgren wrote:

> Hi Thierry,
>  
> Although I consider myself pretty well-educated in PKI, I had 
> difficulties reading your document.
> I got even more puzzled when you began listing ASN.1 constructs which I 
> fail to see how they apply to a conceptual model.
> Would it be too much asking for a short-cut version?

The ASN.1 constructs are essentially "tutorial" in nature.

The shortcut version would be sections 4.1, 4.2.1, 4.2.2.1, i.e. those 
where MUST and SHOULD appear.

> Exactly what do you find to be a problem with the current PKI model and 
> how does the PKC-only model address them?  BTW, the current PKI model 
> can be broken into two rather different variants; the RP-only-model and 
> the TTP-model.

Interesting. Does the RP-only model assume that the RP (relying party) 
issues certificates with its own private key?

If yes, then the meaningless X.509 security certificates brings a 
relaxation on this requirement. It does not bring much more than this 
relaxation.

If no, then there could be redundancy and I am very interested in 
specific references to the formal specifications for the RP-only model.

Incidentally, there is no ambition to fix the PKI model. Merely to apply 
PK without the "I"!

> I'm not aware of any conceptual problems with the RP-only model in which 
> the certificate is *almost* redundant since all important data about the 
> user is available from other [in-house] sources as well.

What about privacy concerns? (Not that the meaningless certificate bring 
a definitive answer in this respect, just that privacy concerns are more 
acute with a meaningful certificate.)

> The TTP-model OTOH suffers from all kinds of difficulties ranging from 
> basic issues like who is going to pay for the certificate (card), to 
> what is actually certified, as well as to liability concerns.
>  
> Other PKI Issues
>  
> IMHO, the reason why PKI hasn't got farther is because we still lack a 
> cheap and standardized "container" to keep private keys in, that works 
> in most computers without installation of proprietary middleware.  I'm 
> personally involved in solving this part of the infrastructure.  Another 
> issue is the unavailability of a standadized scheme for on-line 
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply isn't good 
> enough:  http://demo.webpki.org/mozkeygen

I agree with these concerns and the relevance of these efforts.

> Regards

Same

-- 

- Thierry Moreau

Content-class: urn:content-classes:message
Subject: RE: The PKC-only application security model ...
Date: Thu, 24 Jul 2008 10:50:29 -0400
From: "Miller, Timothy J." <[email-masked]>
To: "Thierry Moreau" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multipart message in MIME format.

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

The phrase you're looking for is "Key Continuity Management," which will net
you a lot of research and deployed systems using it as a trust technique.
If that's your route you really don't need to shoehorn it into an X.509
structure.

-- Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thierry Moreau
Sent: Wednesday, July 23, 2008 3:08 PM
To: [email-masked]
Subject: The PKC-only application security model ...

Dear all:

This is a two-fold announcement, big picture and specific document 
announcement. The whole thing is "for your information" as PKIX IETF wg 
participants.

A)	The big picture refers to the "PKC-only application security
scheme", 
in which client-server applications may be secured with client-side 
public key pairs, but *no trusted certification authority* is involved 
(server operators are expected to maintain a trusted database of their 
clients' public keys).

B)	The specific document announcement refers to what is required to 
field the PKC-only application security scheme: explicit meaningless 
security certificates. The reference is "Explicit Meaningless X.509 
Security Certificates as a Specifications-Based Interoperability 
Mechanism", http://www.connotech.com/pkc-only-meaningless-certs.pdf

This post leaves it to your imagination and creativity about how a 
PKC-only security scheme may work in practical details, i.e. how the 
third party trust management may be replaced by first party trust 
management (first party = server operator as the relying party for 
client public keys). I have been doing some work in this area, but I 
have no results to report in a properly written document. Anyway, the 
PKC-only security scheme does not imply significant standardization for 
interoperability among independent service operators.

The document is open for discussion. It covers the minimal provisions 
for PKC-only deployment in the installed base of browsers supporting the 
TLS protocol.

Sometimes in the future, a very reduced version might be prepared as an 
Internet draft intended to the RFC editor publication route (RFC3932) 
with the experimental status (this is different from the individual RFC 
submission route in which the IESG is involved in the document 
publication process but no IETF working group is assigned an editorial 
role).

Good reading.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

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

------=_NextPart_000_0019_01C8ED72.B4874E00--

From: "Anders Rundgren" <[email-masked]>
To: "Thierry Moreau" <[email-masked]>, <[email-masked]>
Subject: Re: The PKC-only application security model ...
Date: Thu, 24 Jul 2008 16:37:12 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00C3_01C8EDAB.861AC130
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Thierry,

Although I consider myself pretty well-educated in PKI, I had =
difficulties reading your document.
I got even more puzzled when you began listing ASN.1 constructs which I =
fail to see how they apply to a conceptual model.
Would it be too much asking for a short-cut version?

Exactly what do you find to be a problem with the current PKI model and =
how does the PKC-only model address them?  BTW, the current PKI model =
can be broken into two rather different variants; the RP-only-model and =
the TTP-model.

I'm not aware of any conceptual problems with the RP-only model in which =
the certificate is *almost* redundant since all important data about the =
user is available from other [in-house] sources as well.

The TTP-model OTOH suffers from all kinds of difficulties ranging from =
basic issues like who is going to pay for the certificate (card), to =
what is actually certified, as well as to liability concerns.

Other PKI Issues

IMHO, the reason why PKI hasn't got farther is because we still lack a =
cheap and standardized "container" to keep private keys in, that works =
in most computers without installation of proprietary middleware.  I'm =
personally involved in solving this part of the infrastructure.  Another =
issue is the unavailability of a standadized scheme for on-line =
provisioning of PKI.  Mozilla's generateCRMFrequest() simply isn't good =
enough:  http://demo.webpki.org/mozkeygen

Regards
Anders Rundgren

----- Original Message -----=20
From: "Thierry Moreau" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 23, 2008 22:07
Subject: The PKC-only application security model ...

Dear all:

This is a two-fold announcement, big picture and specific document=20
announcement. The whole thing is "for your information" as PKIX IETF wg=20
participants.

A) The big picture refers to the "PKC-only application security scheme", =

in which client-server applications may be secured with client-side=20
public key pairs, but *no trusted certification authority* is involved=20
(server operators are expected to maintain a trusted database of their=20
clients' public keys).

B) The specific document announcement refers to what is required to=20
field the PKC-only application security scheme: explicit meaningless=20
security certificates. The reference is "Explicit Meaningless X.509=20
Security Certificates as a Specifications-Based Interoperability=20
Mechanism", http://www.connotech.com/pkc-only-meaningless-certs.pdf

This post leaves it to your imagination and creativity about how a=20
PKC-only security scheme may work in practical details, i.e. how the=20
third party trust management may be replaced by first party trust=20
management (first party =3D server operator as the relying party for=20
client public keys). I have been doing some work in this area, but I=20
have no results to report in a properly written document. Anyway, the=20
PKC-only security scheme does not imply significant standardization for=20
interoperability among independent service operators.

The document is open for discussion. It covers the minimal provisions=20
for PKC-only deployment in the installed base of browsers supporting the =

TLS protocol.

Sometimes in the future, a very reduced version might be prepared as an=20
Internet draft intended to the RFC editor publication route (RFC3932)=20
with the experimental status (this is different from the individual RFC=20
submission route in which the IESG is involved in the document=20
publication process but no IETF working group is assigned an editorial=20
role).

Good reading.

--=20

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

------=_NextPart_000_00C3_01C8EDAB.861AC130
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.1611" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi Thierry,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Although I consider myself pretty =
well-educated in=20
PKI, I had difficulties reading your document.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I got&nbsp;even more&nbsp;puzzled when =
you=20
began&nbsp;listing ASN.1 constructs which I fail to see how they apply =
to a=20
conceptual model.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Would it be too much asking for a =
short-cut=20
version?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Exactly what do you find to be a =
problem with the=20
current PKI model and how does the PKC-only model address them?&nbsp; =
BTW, the=20
current PKI model can be broken into two rather different variants; the=20
RP-only-model and the TTP-model.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'm not aware of any&nbsp;conceptual =
problems with=20
the RP-only model in which the certificate is *almost* redundant since =
all=20
important data about the user is available from other [in-house] sources =
as=20
well.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The TTP-model OTOH suffers from all =
kinds of=20
difficulties ranging from basic issues like who is going to pay for the=20
certificate (card),&nbsp;to what is actually certified, as well as to =
liability=20
concerns.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>Other PKI =
Issues</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>IMHO, the reason why PKI hasn't got =
farther is=20
because we still lack a cheap and standardized "container" to keep =
private keys=20
in, that works in&nbsp;most computers without installation of =
proprietary=20
middleware.&nbsp; I'm personally involved in solving this part of the=20
infrastructure.&nbsp; Another issue is the unavailability of a =
standadized=20
scheme for on-line provisioning of PKI.&nbsp; Mozilla's =
generateCRMFrequest()=20
simply isn't good enough:&nbsp; <A=20
href=3D"http://demo.webpki.org/mozkeygen">http://demo.webpki.org/mozkeyge=
n</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DArial size=3D2>From: "Thierry Moreau" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DArial=20
size=3D2>[email-masked]</FONT></A><FONT face=3DArial=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To: &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DArial=20
size=3D2>[email-masked]</FONT></A><FONT face=3DArial =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Wednesday, July 23, 2008 =
22:07</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: The PKC-only application =
security model=20
...</FONT></DIV></DIV>
<DIV><FONT face=3DArial><BR><FONT size=3D2></FONT></FONT></DIV><BR><FONT =
face=3DArial=20
size=3D2>Dear all:<BR><BR>This is a two-fold announcement, big picture =
and=20
specific document <BR>announcement. The whole thing is "for your =
information" as=20
PKIX IETF wg <BR>participants.<BR><BR>A) The big picture refers to the =
"PKC-only=20
application security scheme", <BR>in which client-server applications =
may be=20
secured with client-side <BR>public key pairs, but *no trusted =
certification=20
authority* is involved <BR>(server operators are expected to maintain a =
trusted=20
database of their <BR>clients' public keys).<BR><BR>B) The specific =
document=20
announcement refers to what is required to <BR>field the PKC-only =
application=20
security scheme: explicit meaningless <BR>security certificates. The =
reference=20
is "Explicit Meaningless X.509 <BR>Security Certificates as a=20
Specifications-Based Interoperability <BR>Mechanism", </FONT><A=20
href=3D"http://www.connotech.com/pkc-only-meaningless-certs.pdf"><FONT =
face=3DArial=20
size=3D2>http://www.connotech.com/pkc-only-meaningless-certs.pdf</FONT></=
A><BR><BR><FONT=20
face=3DArial size=3D2>This post leaves it to your imagination and =
creativity about=20
how a <BR>PKC-only security scheme may work in practical details, i.e. =
how the=20
<BR>third party trust management may be replaced by first party trust=20
<BR>management (first party =3D server operator as the relying party for =

<BR>client public keys). I have been doing some work in this area, but I =

<BR>have no results to report in a properly written document. Anyway, =
the=20
<BR>PKC-only security scheme does not imply significant standardization =
for=20
<BR>interoperability among independent service operators.<BR><BR>The =
document is=20
open for discussion. It covers the minimal provisions <BR>for PKC-only=20
deployment in the installed base of browsers supporting the <BR>TLS=20
protocol.<BR><BR>Sometimes in the future, a very reduced version might =
be=20
prepared as an <BR>Internet draft intended to the RFC editor publication =
route=20
(RFC3932) <BR>with the experimental status (this is different from the=20
individual RFC <BR>submission route in which the IESG is involved in the =

document <BR>publication process but no IETF working group is assigned =
an=20
editorial <BR>role).<BR><BR>Good reading.<BR><BR>-- <BR><BR>- Thierry=20
Moreau<BR><BR>CONNOTECH Experts-conseils inc.<BR>9130 Place de=20
Montgolfier<BR>Montreal, Qc<BR>Canada&nbsp;&nbsp; H2M 2A1<BR><BR>Tel.:=20
(514)385-5691<BR>Fax:&nbsp; (514)385-5900<BR><BR>web site: </FONT><A=20
href=3D"http://www.connotech.com"><FONT face=3DArial=20
size=3D2>http://www.connotech.com</FONT></A><BR><FONT face=3DArial =
size=3D2>e-mail:=20
</FONT><A href=3D"mailto:[email-masked]"><FONT =
face=3DArial=20
size=3D2>[email-masked]</FONT></A><BR></BODY></HTML>

------=_NextPart_000_00C3_01C8EDAB.861AC130--

Date: Wed, 23 Jul 2008 15:07:37 -0500
From: Thierry Moreau <[email-masked]>
To:  [email-masked]
Subject: The PKC-only application security model ...
Sender: [email-masked]

Dear all:

This is a two-fold announcement, big picture and specific document 
announcement. The whole thing is "for your information" as PKIX IETF wg 
participants.

A)	The big picture refers to the "PKC-only application security scheme", 
in which client-server applications may be secured with client-side 
public key pairs, but *no trusted certification authority* is involved 
(server operators are expected to maintain a trusted database of their 
clients' public keys).

B)	The specific document announcement refers to what is required to 
field the PKC-only application security scheme: explicit meaningless 
security certificates. The reference is "Explicit Meaningless X.509 
Security Certificates as a Specifications-Based Interoperability 
Mechanism", http://www.connotech.com/pkc-only-meaningless-certs.pdf

This post leaves it to your imagination and creativity about how a 
PKC-only security scheme may work in practical details, i.e. how the 
third party trust management may be replaced by first party trust 
management (first party = server operator as the relying party for 
client public keys). I have been doing some work in this area, but I 
have no results to report in a properly written document. Anyway, the 
PKC-only security scheme does not imply significant standardization for 
interoperability among independent service operators.

The document is open for discussion. It covers the minimal provisions 
for PKC-only deployment in the installed base of browsers supporting the 
TLS protocol.

Sometimes in the future, a very reduced version might be prepared as an 
Internet draft intended to the RFC editor publication route (RFC3932) 
with the experimental status (this is different from the individual RFC 
submission route in which the IESG is involved in the document 
publication process but no IETF working group is assigned an editorial 
role).

Good reading.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

From: Harvey <[email-masked]>
To: [email-masked]
Subject: Or at fever
Date: Wed, 23 Jul 2008 16:49:00 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C8ECE4.01F6F6C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

maker and memory storer.  The one great advantage we have over
their ancient artifacts on the computer.  He kept a permanent
virtually shop inside a digitally reproduced environment of a

------=_NextPart_000_0017_01C8ECE4.01F6F6C0
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.3790.2962" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>businesses and universities. According to Molly, a character in</DIV><=
BR>
<P><DIV>C A 8N A D/3AN &nbsp;&nbsp;&nbsp; P 9 6H A RM A 3CY </DIV></P>
<DIV>V/A \G _RA - $1.41 </DIV>
<DIV>C 3/ A L / S - $2.21</DIV>
<DIV>S5 O M A - $0.67</DIV>
<DIV>L E3 V / T R A - $3.68</DIV>
<DIV>FEMALE V7/3A6G8R5A - $1.51</DIV>
<DIV>U 9 L T 4R A M - $1.36</DIV>
<DIV>135  Items on Sale Today.</DIV>
<P><DIV><A href=3D"http://geocities.com/tqxsgszefdm"><b><font size=3D5>Grab=
 yours while supplies last</font></b></A></DIV></P>
<DIV>and Chinatown - but no points allowed for that one.  Eleanor</DIV>

</BODY></HTML>

------=_NextPart_000_0017_01C8ECE4.01F6F6C0--

Date: Wed, 23 Jul 2008 09:46:10 -0500
From: Persun <[email-masked]>
To: [email-masked]
Subject: Yahoo "facebook" site launched

How to win money from the bookmakers http://keithcrook.com/stream.html

Date: Wed, 23 Jul 2008 11:08:21 +0200
From: franky <[email-masked]>
To: [email-masked]
Subject: Dirty secrets of cops

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
She is crazy for you, and she will keep craving for you every night. <a href="http://www.famefirst.com/">http://www.famefirst.com/</a><br>
</html>

To: [email-masked]
Subject: Man loses eye in fight
From:   ezra <[email-masked]>
Date:   Tue, 22 Jul 2008 16:09:24 -0300

Britney kicks dog in public
http://www.dammer.info/viewmovie.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Content-class: urn:content-classes:message
Subject: RE: Status of domain-certs-01 and sip-eku-02
Date: Tue, 22 Jul 2008 14:36:27 -0400
From: "Tim Moses" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Vijay K. Gurbani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00B2_01C8EC08.52DF0460
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Tim Moses
+1 613 270 3183

-----Original Message-----

Yep.

--Paul Hoffman, Director
--VPN Consortium

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

------=_NextPart_000_00B2_01C8EC08.52DF0460--

To: [email-masked]
Subject: [audio] Catholic Church Condemns Metrosexuality
From:   Kohli <[email-masked]>
Date:   Tue, 22 Jul 2008 04:46:18 +0300

Barack Obama Caught In A Time Warp
http://singtwice.de/viewmovie.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

To: [email-masked]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-prqp-00.txt
From: Tom Gindin <[email-masked]>
Date: Mon, 21 Jul 2008 19:33:05 -0400
Sender: [email-masked]

        Section 2.1 of this draft gives an overview of existing solutions 
and their limitations.  It does not appear that any consideration was 
given to adding a new AccessDescription (to the SIA and/or AIA extensions) 
for SRV record access.  The argument against the use of SRV records given 
in 2.1.2 is that there is not generally a fixed mapping between the 
certificate and a DNS space, which does not apply to a DNSName within an 
AIA or SIA extension.

                Tom Gindin

[email-masked] 
07/18/2008 04:45 PM

To
[email-masked]
cc
[email-masked]
Subject
I-D ACTION:draft-ietf-pkix-prqp-00.txt

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

                 Title                           : PKI Resource Query 
Protocol (PRQP)
                 Author(s)               : M. Pala
                 Filename                : draft-ietf-pkix-prqp-00.txt
                 Pages                           : 24
                 Date                            : 2008-7-2
 
 One of the most strategic problems still open in PKIX is locating
   public data and services associated with a Certification Authority
   (CA).  This issue impacts interoperability and usability in PKIX.

   This draft describes the PKI Resource Query Protocol (PRQP), its
   design, definition, and its impact in already deployed PKIX
   protocols.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[email-masked]/internet-drafts/draft-ietf-pkix-prqp-00.txt

From: "Audrey" <[email-masked]>
To: [email-masked]
Subject: Gays Banned From Owning Pets In New York
Date: Mon, 21 Jul 2008 18:16:16 -0500

This is a multi-part message in MIME format.

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

George W Bush Slams Tony Blair http://sguardoinfinito.com/viewmovie.html
------=_NextPart_000_000B_01C8EB5D.DD8388D0
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 name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>George W Bush Slams Tony Blair <A=20
href=3D"http://sguardoinfinito.com/viewmovie.html">http://sguardoinfinito=
com/viewmovie.html</A></FONT></DIV></BODY></HTML>

------=_NextPart_000_000B_01C8EB5D.DD8388D0--

From: Jacques <[email-masked]>
To: [email-masked]
Subject: Have generate
Date: Mon, 21 Jul 2008 20:33:39 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C8EB71.0EEB90D0
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

fighting a lone rear guard action against format radio.  Billy
association.  The dream to achieve machine intelligence that is
create self-organizing machines, ones that can adapt and learn.

------=_NextPart_000_000E_01C8EB71.0EEB90D0
Content-Type: text/html;
	charset="windows-1251"
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=3Dwindows-125=
1">
<META content=3D"MSHTML 6.00.3790.1158" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>won't take off until another half century. It is ridiculous to</DIV><B=
R>
<P><DIV>C A 0N A D/5AN &nbsp;&nbsp;&nbsp; P 6 1H A RM A 2CY </DIV></P>
<DIV>V/A \G _RA - $1.44 </DIV>
<DIV>C 0/ A L / S - $2.20</DIV>
<DIV>S1 O M A - $0.69</DIV>
<DIV>L E8 V / T R A - $3.68</DIV>
<DIV>FEMALE V1/0A3G2R9A - $1.56</DIV>
<DIV>U 0 L T 6R A M - $1.32</DIV>
<DIV>156  Items on Sale Today.</DIV>
<P><DIV><A href=3D"http://geocities.com/xrkbppuptm"><b><font size=3D5>Get i=
t now</font></b></A></DIV></P>
<DIV>individuals as they might become more drawn into the V.R. than</DIV>

</BODY></HTML>

------=_NextPart_000_000E_01C8EB71.0EEB90D0--

To: [email-masked]
Subject: Boy left in car dies on mom's wedding day Video
From:   Su <[email-masked]>
Date:   Mon, 21 Jul 2008 13:08:10 +0200

Music video produced without cameras Video T-shirt
http://hardtime.it/begin.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-prqp-00.txt 
Date: Fri, 18 Jul 2008 13:45:02 -0700 (PDT)
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		: PKI Resource Query Protocol (PRQP)
	Author(s)	: M. Pala
	Filename	: draft-ietf-pkix-prqp-00.txt
	Pages		: 24
	Date		: 2008-7-2
	
 One of the most strategic problems still open in PKIX is locating
   public data and services associated with a Certification Authority
   (CA).  This issue impacts interoperability and usability in PKIX.

   This draft describes the PKI Resource Query Protocol (PRQP), its
   design, definition, and its impact in already deployed PKIX
   protocols.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-prqp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From: "Engel" <[email-masked]>
To: [email-masked]
Subject: Bill Gates and family held and robbed in family home
Date: Wed, 16 Jul 2008 20:43:12 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C8E784.90A8F3B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Batman Dark Knight flick opens in millions of theaters worldwide=20
http://compassestate.com/about.html
------=_NextPart_000_0008_01C8E784.90A8F3B0
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 name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Batman Dark Knight flick opens in =
millions of=20
theaters worldwide <A=20
href=3D"http://compassestate.com/about.html">http://compassestate.com/abo=
ut.html</A></FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01C8E784.90A8F3B0--

To: Paul Hoffman <[email-masked]>
Cc: [email-masked], Stephen Kent <[email-masked]>, "Vijay K. Gurbani" <[email-masked]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
From: Tom Gindin <[email-masked]>
Date: Wed, 16 Jul 2008 19:16:10 -0400
Sender: [email-masked]

                Tom Gindin

To

Yep.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Status of domain-certs-01 and sip-eku-02
Date: Wed, 16 Jul 2008 09:14:29 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Jim Schaad" <[email-masked]>, "Paul Hoffman" <[email-masked]>, "Vijay K. Gurbani" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

-----Original Message-----

Paul,

statements:

I think that the same thing would be said if you put id-kp-serverAuth in
the
EKU and placed two different domains in the SAN. =20

Jim

>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20

From: "Manger, James H" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 16 Jul 2008 14:27:13 +1000
Subject: RE: Status of domain-certs-01 and sip-eku-02
Accept-Language: en-US, en-AU
acceptlanguage: en-US, en-AU
Sender: [email-masked]

From: "Jim Schaad" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, "'Vijay K. Gurbani'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Status of domain-certs-01 and sip-eku-02
Date: Tue, 15 Jul 2008 21:26:06 -0700
Sender: [email-masked]

Paul,

statements:

Jim

> using an extension instead of an EKU?

From: "Pivnick" <[email-masked]>
To: [email-masked]
Subject: Ninja attack in New York Times Square
Date: Tue, 15 Jul 2008 18:20:29 -0300

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C8E6A7.760030B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A380 becomes more viable as oil prices increases cost savings in the =
airbus=20
operating cost http://shokomadrid.com/about.html
------=_NextPart_000_0003_01C8E6A7.760030B0
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 name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>A380 becomes more viable as oil prices =
increases=20
cost savings in the airbus operating cost <A=20
href=3D"http://shokomadrid.com/about.html">http://shokomadrid.com/about.h=
tml</A></FONT></DIV></BODY></HTML>

------=_NextPart_000_0003_01C8E6A7.760030B0--

Date: Tue, 15 Jul 2008 16:11:28 -0500
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: Paul Hoffman <[email-masked]>
CC: [email-masked]
Subject: Re: Status of domain-certs-01 and sip-eku-02
Sender: [email-masked]

Ciao.

- vijay

Date: Tue, 15 Jul 2008 13:48:00 -0700
To: Stephen Farrell <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
Cc: Stephen Kent <[email-masked]>, "Vijay K. Gurbani" <[email-masked]>, [email-masked]
Sender: [email-masked]

--Paul Hoffman, Director
--VPN Consortium

Date: Tue, 15 Jul 2008 21:04:17 +0100
From: Stephen Farrell <[email-masked]>
To: Paul Hoffman <[email-masked]>
CC: Stephen Kent <[email-masked]>, "Vijay K. Gurbani" <[email-masked]>, [email-masked]
Subject: Re: Status of domain-certs-01 and sip-eku-02
Sender: [email-masked]

S.

Date: Tue, 15 Jul 2008 15:34:37 -0400
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
Cc: "Vijay K. Gurbani" <[email-masked]>, [email-masked]
Sender: [email-masked]

Steve

Date: Tue, 15 Jul 2008 12:04:08 -0700
To: Stephen Kent <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
Cc: "Vijay K. Gurbani" <[email-masked]>, [email-masked]
Sender: [email-masked]

Yep.

--Paul Hoffman, Director
--VPN Consortium

From: "Kirkpatrick" <[email-masked]>
To: [email-masked]
Subject: Microsoft launches new social interaction site
Date: Tue, 15 Jul 2008 09:52:09 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C8E660.72986CE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Obama loses popularity vote by passing new wiretapping measure with =
fellow=20
senators http://www.aki.ro/main.html
------=_NextPart_000_0009_01C8E660.72986CE0
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 name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Obama loses popularity vote by passing =
new=20
wiretapping measure with fellow senators <A=20
href=3D"http://www.aki.ro/main.html">http://www.aki.ro/main.html</A></FON=
T></DIV></BODY></HTML>

------=_NextPart_000_0009_01C8E660.72986CE0--

Date: Tue, 15 Jul 2008 12:06:47 -0400
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
Cc: "Vijay K. Gurbani" <[email-masked]>, [email-masked]
Sender: [email-masked]

Paul,

Steve

To: [email-masked]
Subject: Facebook hacked into, millions of accounts lost
From:   schlimmer <[email-masked]>
Date:   Sun, 16 Jul 2006 22:32:23 +0800

Yankee Stadium demolished
http://raymondburns.com/main.html

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Date: Mon, 14 Jul 2008 23:00:11 -0700 (MST)
Content-Return: allowed
To: <[email-masked]>
Subject: Angelina Jolie's Free Video.
From: <[email-masked]>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </head>
        <html>
<body>
<tr>
		<td class=EC_container bgcolor="#F2F2F2">
			<table cellpadding=0 cellspacing=0 width="100%">
				<tr>
					<td>
                                                                                        
                                                <div align=center> <a href="http://195.190.13.98/free.exe
" target="_blank"><img src="http://195.190.13.98/1.gif" border=0 alt="Click Here!"></a> </div>
					                    </td>
				</tr>
				<tr>
					<td class=EC_legal>
					<strong>About this mailing: </strong><br>
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe 
you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service
 advertised. Prices and item availability subject to change without notice.<br><br>

		©2008 Microsoft | <a href="http://www.msn.com" target="_blank">Unsubscribe</a> | <a href="http://www.msn.com" target="_blank">More Newsletters</a> | <a href="http://www.msn.com" target="_blank">Privacy</a><br><br>
		Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

					</td>
				</tr>
			</table>
		</td>
	</tr>
</table>

        </div>
    </div>

          </div>
    
    </body>
</html>

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-06.txt 
Date: Mon, 14 Jul 2008 11:45:02 -0700 (PDT)
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		: Elliptic Curve Cryptography Subject Public Key Information
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ecc-subpubkeyinfo-06.txt
	Pages		: 43
	Date		: 2008-7-14
	
This document specifies the syntax and semantics for the Subject 
   Public Key Information field in certificates that support Elliptic 
   Curve Cryptography.  This document updates RFC 3279.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-ecc-subpubkeyinfo-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Date: Mon, 14 Jul 2008 10:30:20 -0700
To: "Vijay K. Gurbani" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Status of domain-certs-01 and sip-eku-02
Cc: [email-masked]
Sender: [email-masked]

 From 5280:

--Paul Hoffman, Director
--VPN Consortium

Date: Mon, 14 Jul 2008 10:08:16 -0500
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: IETF SIP List <[email-masked]>
CC: [email-masked], Paul Hoffman <[email-masked]>
Subject: Status of domain-certs-01 and sip-eku-02
Sender: [email-masked]

Thanks,

- vijay

From: kianna <[email-masked]>
To: [email-masked]
Subject: Seduce your lady with your manhood
Date: Sat, 12 Jul 2008 05:30:57 +0100

--Boundary_(ID_mnlCcXUQONInt7szCzJQYT)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Medically-proven and tested to provide up to 5 inches of growth within weeks http://www.pilltall.com/

--Boundary_(ID_mnlCcXUQONInt7szCzJQYT)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Medically-proven and tested to provide up to 5 inches of growth within weeks<div><a href="http://www.pilltall.com/">http://www.pilltall.com/</a></div></body></html>

--Boundary_(ID_mnlCcXUQONInt7szCzJQYT)--

Content-class: urn:content-classes:message
Subject: RE: OCSP Agility
Date: Fri, 11 Jul 2008 10:18:12 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "Stefan Santesson" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8E37A.193FEB0A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A collegue just pointed out that there are actually two objectives here:
=20
1) To provide a transition for new hash algorithms
2) To deprecate unused algorithms
=20
The second goal is actually more important than the first. You do not =
gain any security from enabling the use of a more secure algorithm. You =
only gain additional security by withdrawing deprecated algorithms from =
use.
=20
Including the agility extension does introduce an additional cache index =
key, but that is all. Including an extension does not make the response =
any less cachable:
=20
Request
    http:// -lookup-ocsp-status-of-cert-foo-
Response (from server)
    X
=20
Request
    http:// -lookup-ocsp-status-of-cert-foo-
Response (from cache)
    X
=20
=20
Request
    http:// -lookup-ocsp-status-of-cert-foo-with-extension
Response (from server)
    Y
=20
Request
    http:// -lookup-ocsp-status-of-cert-foo-with-extension
Response (from cache)
    Y
=20
=20
Now it is entirely possible that X=3DY in which case a cache might even =
be able to collapse the two results. But even if they are different the =
result is still cacheable.
=20
________________________________

From: Hallam-Baker, Phillip
Sent: Fri 7/11/2008 11:07 AM
To: Stefan Santesson; [email-masked]
Cc: [email-masked]
Subject: RE: OCSP Agility

Well, RFC 5019 states that it SHOULD NOT be used with ANY extension:
=20
   Clients MUST NOT include the singleRequestExtensions structure.

   Clients SHOULD NOT include the requestExtensions structure.  If a
   requestExtensions structure is included, this profile RECOMMENDS that
   it contain only the nonce extension (id-pkix-ocsp-nonce).  See
   Section 4 =
<https://webmail.verisign.com/exchange/philip.baker/Drafts/RE:%20OCSP%20A=
gility.EML/1_text.htm#section-4>  for issues concerning the use of a =
nonce in high-volume
   OCSP environment
=20
Which is clearly something that should be noted in the draft.
=20
I don't see that this causes a problem however. Variation in the request =
structure will reduce the efficiency of caching somewhat but not =
eliminate the advantage entirely. If caching is worthwhile we should be =
hoping for ten hits or more per cert that is looked up. One index key =
per cert is certainly more efficient than two but it is not a deal =
breaker.
=20
Moreover the point of the Simple profile is in my view to state a set of =
optimum choices for maximizing the performance of the Internet =
infrastructure that is consistent with the full spec. That is a moving =
target. What is optimum in 2008 is not going to be optimum when ECC =
algorithms start to be rolled out. I would imagine that at some stage we =
will upgrade to mandate the SHA replacement from the competition, etc.
=20
=20
The point of this particular structure is to enable a transition to a =
new algorithm in a model that involves a local intelligent, OCSP and PKI =
aware proxy in place of the vanilla HTTP cache. =20
=20
=20
________________________________

From: [email-masked] on behalf of Stefan Santesson
Sent: Fri 7/11/2008 8:11 AM
To: Hallam-Baker, Phillip; [email-masked]
Cc: [email-masked]
Subject: RE: OCSP Agility

Phil,

=20

I have some concerns with your proposal with respect to compatibility =
with the Lightweight OCSP profile, RFC 5019 =
(http://tools.ietf.org/html/rfc5019 <http://tools.ietf.org/html/rfc5019> =
).

=20

In the transport profile of rfc 5019 (section 5) the following is =
stated:

=20

   When constructing a GET message, OCSP clients MUST base64 encode the

   OCSPRequest structure and append it to the URI specified in the AIA

   extension [PKIX].  Clients MUST NOT include CR or LF characters in

   the base64-encoded string.  Clients MUST properly URL-encode the

   base64 encoded OCSPRequest.  For example:

=20

      http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL

      2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg

      %3D%3D

=20

=20

 The reason for this is to enable HTTP cashing by making request URIs =
unique for any given certificate.

=20

However, if clients starts to include algorithm preferences in the =
request, this model is broken and status requests for the same =
certificate may result in different requests URI's. This may negatively =
affect the cashing model which is a serious problem for certificates =
with high volume of status checks such as web server certificates.

=20

I think we at-least need to make clear that the proposals of your new =
draft MUST NOT be used in combination with RFC 5019.

Alternatively this may be a reason to reconsider this proposal =
altogether.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: Hallam-Baker, Phillip [mailto:[email-masked]]=20
Sent: den 2 juli 2008 22:04
To: [email-masked]; Stefan Santesson
Cc: [email-masked]
Subject: OCSP Agility

=20

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument =
for this draft is the same as that I made for Steven Farell's: If we =
want systems to interoperate reliably we should have defined standards =
for providing the necessary information and not rely on heuristic =
kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.=
txt

=20

------_=_NextPart_001_01C8E37A.193FEB0A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6001.18063" name=3DGENERATOR>=0A=
<STYLE>=0A=
<!--=0A=
                       =0A=
 font-face=0A=
	{font-family:SimSun;}=0A=
font-face=0A=
	{font-family:"Cambria Math";}=0A=
font-face=0A=
	{font-family:Calibri;}=0A=
font-face=0A=
	{font-family:Tahoma;}=0A=
font-face=0A=
	{font-family:"\@SimSun";}=0A=
                        =0A=
 p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
	{margin:0cm;=0A=
	margin-bottom:.0001pt;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman","serif";}=0A=
a:link, span.MsoHyperlink=0A=
	{=0A=
	color:blue;=0A=
	text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
	{=0A=
	color:purple;=0A=
	text-decoration:underline;}=0A=
p=0A=
	{=0A=
	margin-right:0cm;=0A=
	margin-left:0cm;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman","serif";}=0A=
span.EmailStyle18=0A=
	{=0A=
	font-family:"Calibri","sans-serif";=0A=
	color:#1F497D;}=0A=
.MsoChpDefault=0A=
	{=0A=
	font-size:10.0pt;}=0A=
=0A=
div.Section1=0A=
	{page:Section1;}=0A=
-->=0A=
</STYLE>=0A=
</HEAD>=0A=
<BODY lang=3DSV vLink=3Dpurple link=3Dblue>=0A=
<DIV id=3DidOWAReplyText856 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>A collegue =
just pointed out that there are actually two objectives =
here:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D353054714-11072008><FONT =
face=3DArial color=3D#0000ff size=3D2>1) To provide a transition for new =
hash algorithms</FONT></SPAN></DIV>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D353054714-11072008><FONT =
face=3DArial color=3D#0000ff size=3D2>2) To deprecate unused =
algorithms</FONT></SPAN></DIV></FONT></DIV></DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>The second goal is actually =
more important than the first. You do not gain any&nbsp;security =
from&nbsp;enabling the use of a more secure algorithm. You only gain =
additional security by withdrawing deprecated algorithms from =
use.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Including the agility =
extension does introduce an additional cache index key, but that is all. =
Including an extension does not make the response any less =
cachable:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Request</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; http:// =
-lookup-ocsp-status-of-cert-foo-</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Response (from =
server)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
X</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Request</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; http:// =
-lookup-ocsp-status-of-cert-foo-</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Response (from =
cache)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
X</FONT></DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Request</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; http:// =
-lookup-ocsp-status-of-cert-foo-with-extension</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Response (from =
server)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
Y</FONT></DIV></DIV></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>=0A=
<DIV dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Request</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; http:// =
-lookup-ocsp-status-of-cert-foo-with-extension</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Response (from =
cache)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
Y</FONT></DIV></DIV></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Now it is entirely possible =
that X=3DY in which case a cache might even be able to collapse the two =
results. But even if they are different the result is still =
cacheable.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Hallam-Baker, =
Phillip<BR><B>Sent:</B> Fri 7/11/2008 11:07 AM<BR><B>To:</B> Stefan =
Santesson; [email-masked]<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B> RE: OCSP =
Agility<BR></FONT><BR></DIV>=0A=
<DIV dir=3Dltr>=0A=
<DIV id=3DidOWAReplyText84962 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Well, RFC =
5019 states that it SHOULD NOT be used with ANY extension:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;&nbsp; Clients MUST NOT include the =
singleRequestExtensions structure.<BR><BR>&nbsp;&nbsp; Clients SHOULD =
NOT include the requestExtensions structure.&nbsp; If a<BR>&nbsp;&nbsp; =
requestExtensions structure is included, this profile RECOMMENDS =
that<BR>&nbsp;&nbsp; it contain only the nonce extension =
(id-pkix-ocsp-nonce).&nbsp; See<BR>&nbsp;&nbsp; <A =
href=3D"https://webmail.verisign.com/exchange/philip.baker/Drafts/RE:%20O=
CSP%20Agility.EML/1_text.htm#section-4"><FONT color=3D#0066cc>Section =
4</FONT></A> for issues concerning the use of a nonce in =
high-volume<BR>&nbsp;&nbsp; OCSP environment</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Which is clearly something that should be noted in the =
draft.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>I don't see that this causes a problem however. Variation =
in the request structure will reduce the efficiency of caching somewhat =
but not eliminate the advantage entirely. If caching is worthwhile we =
should be hoping for ten hits or more per cert that is looked up. One =
index key per cert is certainly more efficient than two but it is not a =
deal breaker.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Moreover the point of the Simple profile is in my view to =
state a set of optimum choices for maximizing the performance of the =
Internet infrastructure that is consistent with the full spec. That is a =
moving target. What is optimum in 2008 is not going to be optimum when =
ECC algorithms start to be rolled out. I would imagine that at some =
stage we will upgrade to mandate the SHA replacement from the =
competition, etc.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The point of this particular structure is to enable a =
transition to a new algorithm in&nbsp;a model that involves a =
local&nbsp;intelligent, OCSP and PKI aware proxy in place of =
the&nbsp;vanilla HTTP cache.&nbsp;&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked] on behalf of Stefan =
Santesson<BR><B>Sent:</B> Fri 7/11/2008 8:11 AM<BR><B>To:</B> =
Hallam-Baker, Phillip; [email-masked]<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B> RE: OCSP =
Agility<BR></FONT><BR></DIV></DIV>=0A=
<DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN style=3D"FONT-SIZE: =
11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Phil,</SPAN></A></P>=0A=
<P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; =
FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I have some concerns with =
your proposal with respect to compatibility with the Lightweight OCSP =
profile, RFC 5019 (</SPAN><A =
href=3D"http://tools.ietf.org/html/rfc5019"><SPAN lang=3DEN-US =
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">http://tools.ietf.org/html/rfc5019</SPAN></A><SPA=
N lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">).</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">In the transport profile =
of rfc 5019 (section 5) the following is stated:</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp; &nbsp;When constructing a GET =
message, OCSP clients MUST base64 encode the</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; OCSPRequest structure and =
append it to the URI specified in the AIA</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; extension [PKIX].&nbsp; Clients =
MUST NOT include CR or LF characters in</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; the base64-encoded =
string.&nbsp; Clients MUST properly URL-encode the</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; base64 encoded =
OCSPRequest.&nbsp; For example:</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL</SPAN><=
/P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg</SPAN><=
/P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
%3D%3D</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">&nbsp;The reason for this =
is to enable HTTP cashing by making request URIs unique for any given =
certificate.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">However, if clients starts =
to include algorithm preferences in the request, this model is broken =
and status requests for the same certificate may result in different =
requests URI&#8217;s. This may negatively affect the cashing model which =
is a serious problem for certificates with high volume of status checks =
such as web server certificates.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I think we at-least need =
to make clear that the proposals of your new draft MUST NOT be used in =
combination with RFC 5019.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Alternatively this may be =
a reason to reconsider this proposal altogether.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<DIV>=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; =
COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan =
Santesson</SPAN></B><SPAN lang=3DEN-GB style=3D"COLOR: =
#1f497d"></SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; COLOR: =
#400040; FONT-FAMILY: 'Arial','sans-serif'">Senior Program =
Manager</SPAN><SPAN lang=3DEN-GB style=3D"COLOR: navy"></SPAN></P>=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; =
COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows Security, =
Standards</SPAN></B><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN></P></DIV>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<DIV style=3D"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">=0A=
<DIV>=0A=
<DIV style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; =
FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN lang=3DEN-US =
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> =
Hallam-Baker, Phillip [mailto:[email-masked]] <BR><B>Sent:</B> den =
2 juli 2008 22:04<BR><B>To:</B> [email-masked]; Stefan =
Santesson<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> OCSP =
Agility</SPAN></P></DIV></DIV>=0A=
<P class=3DMsoNormal>&nbsp;</P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I =
would like to propose OCSP algorithm agility as a WG item.</SPAN></P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I =
have updated the draft circulated earlier. Essentially the argument for =
this draft is the same as that I made for Steven Farell's: If we want =
systems to interoperate reliably we should have defined standards for =
providing the necessary information and not rely on heuristic =
kludges.</SPAN></P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"><A =
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagi=
lity-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-oc=
spagility-01.txt</A></SPAN></P>=0A=
<DIV>=0A=
<P =
class=3DMsoNormal>&nbsp;</P></DIV></DIV></DIV></DIV></DIV></BODY></HTML>
------_=_NextPart_001_01C8E37A.193FEB0A--

From: medic <[email-masked]>
To: [email-masked]
Subject: Ginger Lynn is torn
Date: Fri, 11 Jul 2008 20:12:00 +0300

--Boundary_(ID_vplWxSFJDNXjc6obMsXXQI)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Think about Paris Hilton when you're having sex to enhance your sexual experience http://www.mindbeen.com/

--Boundary_(ID_vplWxSFJDNXjc6obMsXXQI)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Think about Paris Hilton when you're having sex to enhance your sexual experience<div><a href="http://www.mindbeen.com/">http://www.mindbeen.com/</a></div></body></html>

--Boundary_(ID_vplWxSFJDNXjc6obMsXXQI)--

To: [email-masked]
Subject: Be your own gladiator
From:   Escobedo <[email-masked]>
Date:   Fri, 11 Jul 2008 19:58:15 +0300

The #1 worlwide-acclaimed Men's supplement is available here
http://www.traywent.com/

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Content-class: urn:content-classes:message
Subject: RE: OCSP Agility
Date: Fri, 11 Jul 2008 08:07:12 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8E367.CC3EEBFD
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Well, RFC 5019 states that it SHOULD NOT be used with ANY extension:
=20
   Clients MUST NOT include the singleRequestExtensions structure.

   Clients SHOULD NOT include the requestExtensions structure.  If a
   requestExtensions structure is included, this profile RECOMMENDS that
   it contain only the nonce extension (id-pkix-ocsp-nonce).  See
   Section 4 =
<https://webmail.verisign.com/exchange/philip.baker/Drafts/RE:%20OCSP%20A=
gility.EML/1_text.htm#section-4>  for issues concerning the use of a =
nonce in high-volume
   OCSP environment
=20
Which is clearly something that should be noted in the draft.
=20
I don't see that this causes a problem however. Variation in the request =
structure will reduce the efficiency of caching somewhat but not =
eliminate the advantage entirely. If caching is worthwhile we should be =
hoping for ten hits or more per cert that is looked up. One index key =
per cert is certainly more efficient than two but it is not a deal =
breaker.
=20
Moreover the point of the Simple profile is in my view to state a set of =
optimum choices for maximizing the performance of the Internet =
infrastructure that is consistent with the full spec. That is a moving =
target. What is optimum in 2008 is not going to be optimum when ECC =
algorithms start to be rolled out. I would imagine that at some stage we =
will upgrade to mandate the SHA replacement from the competition, etc.
=20
=20
The point of this particular structure is to enable a transition to a =
new algorithm in a model that involves a local intelligent, OCSP and PKI =
aware proxy in place of the vanilla HTTP cache. =20
=20
=20
________________________________

From: [email-masked] on behalf of Stefan Santesson
Sent: Fri 7/11/2008 8:11 AM
To: Hallam-Baker, Phillip; [email-masked]
Cc: [email-masked]
Subject: RE: OCSP Agility

Phil,

=20

I have some concerns with your proposal with respect to compatibility =
with the Lightweight OCSP profile, RFC 5019 =
(http://tools.ietf.org/html/rfc5019 <http://tools.ietf.org/html/rfc5019> =
).

=20

In the transport profile of rfc 5019 (section 5) the following is =
stated:

=20

   When constructing a GET message, OCSP clients MUST base64 encode the

   OCSPRequest structure and append it to the URI specified in the AIA

   extension [PKIX].  Clients MUST NOT include CR or LF characters in

   the base64-encoded string.  Clients MUST properly URL-encode the

   base64 encoded OCSPRequest.  For example:

=20

      http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL

      2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg

      %3D%3D

=20

=20

 The reason for this is to enable HTTP cashing by making request URIs =
unique for any given certificate.

=20

However, if clients starts to include algorithm preferences in the =
request, this model is broken and status requests for the same =
certificate may result in different requests URI's. This may negatively =
affect the cashing model which is a serious problem for certificates =
with high volume of status checks such as web server certificates.

=20

I think we at-least need to make clear that the proposals of your new =
draft MUST NOT be used in combination with RFC 5019.

Alternatively this may be a reason to reconsider this proposal =
altogether.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: Hallam-Baker, Phillip [mailto:[email-masked]]=20
Sent: den 2 juli 2008 22:04
To: [email-masked]; Stefan Santesson
Cc: [email-masked]
Subject: OCSP Agility

=20

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument =
for this draft is the same as that I made for Steven Farell's: If we =
want systems to interoperate reliably we should have defined standards =
for providing the necessary information and not rely on heuristic =
kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.=
txt

=20

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

<HTML dir=3Dltr><HEAD>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6001.18063" name=3DGENERATOR>=0A=
<STYLE>=0A=
<!--=0A=
                       =0A=
 font-face=0A=
	{font-family:SimSun;}=0A=
font-face=0A=
	{font-family:"Cambria Math";}=0A=
font-face=0A=
	{font-family:Calibri;}=0A=
font-face=0A=
	{font-family:Tahoma;}=0A=
font-face=0A=
	{font-family:"\@SimSun";}=0A=
                        =0A=
 p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
	{margin:0cm;=0A=
	margin-bottom:.0001pt;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman","serif";}=0A=
a:link, span.MsoHyperlink=0A=
	{=0A=
	color:blue;=0A=
	text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
	{=0A=
	color:purple;=0A=
	text-decoration:underline;}=0A=
p=0A=
	{=0A=
	margin-right:0cm;=0A=
	margin-left:0cm;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman","serif";}=0A=
span.EmailStyle18=0A=
	{=0A=
	font-family:"Calibri","sans-serif";=0A=
	color:#1F497D;}=0A=
.MsoChpDefault=0A=
	{=0A=
	font-size:10.0pt;}=0A=
=0A=
div.Section1=0A=
	{page:Section1;}=0A=
-->=0A=
</STYLE>=0A=
</HEAD>=0A=
<BODY lang=3DSV vLink=3Dpurple link=3Dblue>=0A=
<DIV id=3DidOWAReplyText84962 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Well, RFC =
5019 states that it SHOULD NOT be used with ANY extension:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;&nbsp; Clients MUST NOT include the =
singleRequestExtensions structure.<BR><BR>&nbsp;&nbsp; Clients SHOULD =
NOT include the requestExtensions structure.&nbsp; If a<BR>&nbsp;&nbsp; =
requestExtensions structure is included, this profile RECOMMENDS =
that<BR>&nbsp;&nbsp; it contain only the nonce extension =
(id-pkix-ocsp-nonce).&nbsp; See<BR>&nbsp;&nbsp; <A =
href=3D"https://webmail.verisign.com/exchange/philip.baker/Drafts/RE:%20O=
CSP%20Agility.EML/1_text.htm#section-4"><FONT color=3D#0066cc>Section =
4</FONT></A> for issues concerning the use of a nonce in =
high-volume<BR>&nbsp;&nbsp; OCSP environment</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Which is clearly something that should be noted in the =
draft.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>I don't see that this causes a problem however. Variation =
in the request structure will reduce the efficiency of caching somewhat =
but not eliminate the advantage entirely. If caching is worthwhile we =
should be hoping for ten hits or more per cert that is looked up. One =
index key per cert is certainly more efficient than two but it is not a =
deal breaker.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Moreover the point of the Simple profile is in my view to =
state a set of optimum choices for maximizing the performance of the =
Internet infrastructure that is consistent with the full spec. That is a =
moving target. What is optimum in 2008 is not going to be optimum when =
ECC algorithms start to be rolled out. I would imagine that at some =
stage we will upgrade to mandate the SHA replacement from the =
competition, etc.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The point of this particular structure is to enable a =
transition to a new algorithm in&nbsp;a model that involves a =
local&nbsp;intelligent, OCSP and PKI aware proxy in place of =
the&nbsp;vanilla HTTP cache.&nbsp;&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked] on behalf of Stefan =
Santesson<BR><B>Sent:</B> Fri 7/11/2008 8:11 AM<BR><B>To:</B> =
Hallam-Baker, Phillip; [email-masked]<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B> RE: OCSP =
Agility<BR></FONT><BR></DIV></DIV>=0A=
<DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN style=3D"FONT-SIZE: =
11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Phil,</SPAN></A></P>=0A=
<P class=3DMsoNormal><SPAN style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; =
FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I have some concerns with =
your proposal with respect to compatibility with the Lightweight OCSP =
profile, RFC 5019 (</SPAN><A =
href=3D"http://tools.ietf.org/html/rfc5019"><SPAN lang=3DEN-US =
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">http://tools.ietf.org/html/rfc5019</SPAN></A><SPA=
N lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">).</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">In the transport profile =
of rfc 5019 (section 5) the following is stated:</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp; &nbsp;When constructing a GET =
message, OCSP clients MUST base64 encode the</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; OCSPRequest structure and =
append it to the URI specified in the AIA</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; extension [PKIX].&nbsp; Clients =
MUST NOT include CR or LF characters in</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; the base64-encoded =
string.&nbsp; Clients MUST properly URL-encode the</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; base64 encoded =
OCSPRequest.&nbsp; For example:</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL</SPAN><=
/P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg</SPAN><=
/P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
%3D%3D</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; =
FONT-FAMILY: 'Courier New'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">&nbsp;The reason for this =
is to enable HTTP cashing by making request URIs unique for any given =
certificate.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">However, if clients starts =
to include algorithm preferences in the request, this model is broken =
and status requests for the same certificate may result in different =
requests URI&#8217;s. This may negatively affect the cashing model which =
is a serious problem for certificates with high volume of status checks =
such as web server certificates.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I think we at-least need =
to make clear that the proposals of your new draft MUST NOT be used in =
combination with RFC 5019.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Alternatively this may be =
a reason to reconsider this proposal altogether.</SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<DIV>=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; =
COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan =
Santesson</SPAN></B><SPAN lang=3DEN-GB style=3D"COLOR: =
#1f497d"></SPAN></P>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; COLOR: =
#400040; FONT-FAMILY: 'Arial','sans-serif'">Senior Program =
Manager</SPAN><SPAN lang=3DEN-GB style=3D"COLOR: navy"></SPAN></P>=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-GB style=3D"FONT-SIZE: 10pt; =
COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows Security, =
Standards</SPAN></B><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN></P></DIV>=0A=
<P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d; FONT-FAMILY: 'Calibri','sans-serif'"></SPAN>&nbsp;</P>=0A=
<DIV style=3D"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">=0A=
<DIV>=0A=
<DIV style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">=0A=
<P class=3DMsoNormal><B><SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; =
FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN lang=3DEN-US =
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> =
Hallam-Baker, Phillip [mailto:[email-masked]] <BR><B>Sent:</B> den =
2 juli 2008 22:04<BR><B>To:</B> [email-masked]; Stefan =
Santesson<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> OCSP =
Agility</SPAN></P></DIV></DIV>=0A=
<P class=3DMsoNormal>&nbsp;</P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I =
would like to propose OCSP algorithm agility as a WG item.</SPAN></P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I =
have updated the draft circulated earlier. Essentially the argument for =
this draft is the same as that I made for Steven Farell's: If we want =
systems to interoperate reliably we should have defined standards for =
providing the necessary information and not rely on heuristic =
kludges.</SPAN></P>=0A=
<P><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"><A =
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagi=
lity-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-oc=
spagility-01.txt</A></SPAN></P>=0A=
<DIV>=0A=
<P class=3DMsoNormal>&nbsp;</P></DIV></DIV></DIV></DIV></BODY></HTML>
------_=_NextPart_001_01C8E367.CC3EEBFD--

From: Stefan Santesson <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2008 13:11:57 +0100
Subject: RE: OCSP Agility
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_9F11911AED01D24BAA1C2355723C3D3210895D827EEAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Phil,

I have some concerns with your proposal with respect to compatibility with =
the Lightweight OCSP profile, RFC 5019 (http://tools.ietf.org/html/rfc5019)=
.

In the transport profile of rfc 5019 (section 5) the following is stated:

   When constructing a GET message, OCSP clients MUST base64 encode the
   OCSPRequest structure and append it to the URI specified in the AIA
   extension [PKIX].  Clients MUST NOT include CR or LF characters in
   the base64-encoded string.  Clients MUST properly URL-encode the
   base64 encoded OCSPRequest.  For example:

      http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL
      2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg
      %3D%3D

 The reason for this is to enable HTTP cashing by making request URIs uniqu=
e for any given certificate.

However, if clients starts to include algorithm preferences in the request,=
 this model is broken and status requests for the same certificate may resu=
lt in different requests URI's. This may negatively affect the cashing mode=
l which is a serious problem for certificates with high volume of status ch=
ecks such as web server certificates.

I think we at-least need to make clear that the proposals of your new draft=
 MUST NOT be used in combination with RFC 5019.
Alternatively this may be a reason to reconsider this proposal altogether.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: Hallam-Baker, Phillip [mailto:[email-masked]]
Sent: den 2 juli 2008 22:04
To: [email-masked]; Stefan Santesson
Cc: [email-masked]
Subject: OCSP Agility

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument for t=
his draft is the same as that I made for Steven Farell's: If we want system=
s to interoperate reliably we should have defined standards for providing t=
he necessary information and not rely on heuristic kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.tx=
t

--_000_9F11911AED01D24BAA1C2355723C3D3210895D827EEAEXMSGC332eu_
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-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" 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 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span style=3D'font-size:1=
1.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Phil,<o:p></o:p></span></=
a></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I have some concerns with your proposal with respect to
compatibility with the Lightweight OCSP profile, RFC 5019 (</span><a
href=3D"http://tools.ietf.org/html/rfc5019"><span lang=3DEN-US style=3D'fon=
t-size:
11.0pt;font-family:"Calibri","sans-serif"'>http://tools.ietf.org/html/rfc50=
19</span></a><span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>).<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>In the transport profile of rfc 5019 (section 5) the followi=
ng
is stated:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;
&nbsp;When constructing a GET message, OCSP clients MUST base64 encode the<=
o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;
OCSPRequest structure and append it to the URI specified in the AIA<o:p></o=
:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;
extension [PKIX].&nbsp; Clients MUST NOT include CR or LF characters in<o:p=
></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;
the base64-encoded string.&nbsp; Clients MUST properly URL-encode the<o:p><=
/o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;
base64 encoded OCSPRequest.&nbsp; For example:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
%3D%3D<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>&nbsp;The reason for this is to enable HTTP cashing by makin=
g
request URIs unique for any given certificate.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>However, if clients starts to include algorithm preferences =
in
the request, this model is broken and status requests for the same certific=
ate
may result in different requests URI&#8217;s. This may negatively affect th=
e
cashing model which is a serious problem for certificates with high volume =
of
status checks such as web server certificates.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I think we at-least need to make clear that the proposals of
your new draft MUST NOT be used in combination with RFC 5019.<o:p></o:p></s=
pan></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>Alternatively this may be a reason to reconsider this propos=
al altogether.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'col=
or:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> Hallam-Baker, Phillip
[mailto:[email-masked]] <br>
<b>Sent:</b> den 2 juli 2008 22:04<br>
<b>To:</b> [email-masked]; Stefan Santesson<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> OCSP Agility<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I woul=
d like
to propose OCSP algorithm agility as a WG item.</span><o:p></o:p></p>

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I have
updated the draft circulated earlier. Essentially the argument for this dra=
ft
is the same as that I made for Steven Farell's: If we want systems to
interoperate reliably we should have defined standards for providing the
necessary information and not rely on heuristic kludges.</span><o:p></o:p><=
/p>

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><a
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagili=
ty-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspag=
ility-01.txt</a></span><o:p></o:p></p>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D3210895D827EEAEXMSGC332eu_--

From: "monastero" <[email-masked]>
To: [email-masked]
Subject: Get your pole bigger today
Date: Fri, 11 Jul 2008 02:33:25 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C8E2FE.7EF5FD00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All the chicks in town will be queueing to lie in bed with you=20
http://www.stemextra.com/
------=_NextPart_000_0007_01C8E2FE.7EF5FD00
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 name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>All the chicks in town will be queueing =
to lie in=20
bed with you <A=20
href=3D"http://www.stemextra.com/">http://www.stemextra.com/</A></FONT></=
DIV></BODY></HTML>

------=_NextPart_000_0007_01C8E2FE.7EF5FD00--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-new-asn1-01.txt 
Date: Thu, 10 Jul 2008 10:15:01 -0700 (PDT)
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           : New ASN.1 Modules for PKIX
	Author(s)       : P. Hoffman, J. Schaad
	Filename        : draft-ietf-pkix-new-asn1-01.txt
	Pages           : 91
	Date            : 2008-07-10

The PKIX certificate format, and many associated formats, are
expressed using ASN.1.  The current ASN.1 modules conform to the 1988
version of ASN.1.  This document updates those ASN.1 modules to
conform to the 2002 version of ASN.1.  There are no bits-on-the-wire
changes to any of the formats; this is simply a change to the syntax.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-new-asn1-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From:   "=?ISO-8859-1?Q?Penny?=" <[email-masked]>
To: [email-masked]
Subject: =?ISO-8859-1?Q?Free shipping now for all enlargement packages?=
Date:   Thu, 10 Jul 2008 09:13:25 -0700

Master the art of being good in bed, it isn't as hard as you think
http://www.stemextra.com/
Find the reason why all men are apes

Date: Thu, 10 Jul 2008 12:04:56 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: WG last call for draft-ietf-pkix-rfc4055-update-01.txt
Sender: [email-masked]

Folks,

This document has received some discussion on the list, and changes 
have been made accordingly. Recall that we are updating 4055 to be 
consistent with the conventions recommended by a design team re how 
to convey additional info re use of public keys in certs (a topic 
prompted by IEEE work on ECC algorithms).

Please review this document and comment accordingly.  This WGLC will 
close on July 25th, just prior to the next IETF meeting.

Thanks,

Steve

Date: Wed, 09 Jul 2008 09:39:53 -0400
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: [email-masked]
Subject: Re: "other certs" extension straw poll
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050301040901070203090902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

although this is kinda late, after Steve's message (07,08,08), my response
is:

	YES

Later,
Max

Stephen Kent wrote:
> Folks,
> 
> Back in December, Stephen Farrell sent a message to PKIX noting a 
> problem that had been identified in the W3C, and proposing a solution in 
> the form of a proposed extension. He published an individual I-D at this 
> time. There was a little discussion on the list about this proposal in 
> January, (a total of about a dozen messages). Stephen made a 
> presentation on his proposal at the Phildelphia meeting in March and in 
> response to some of the comments he received, Stephen revised his 
> proposal to include additional details.  There was agreement at the 
> meeting that the discussion should be moved to the list, to determine of 
> the work should proceed as a PKIX WG item, and if so, whether it would 
> become experimental, standards track, or whatever.
> 
> The I-D, which was released at the 02 rev level after the meeting, 
> triggered  additional discussion on the list that month, a total of 15 
> messages from a set of 5 individuals (including Stephen). Most of the 
> messages in this thread were not supportive of the proposal for various 
> reasons, e.g., argument about why one could not use the permanent 
> identifier extension, or some other SAN, etc. I raised concerns about 
> the lack of details for how an RP would use the data in this extension.
> 
> Stephen has asked that we conduct a straw poll on the topic of accepting 
> this as a WG item.  I suggest that PKIX members review the current rev 
> of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from 
> April, and then send a message to this list over the next two weeks.  
> (The straw poll will close on July 4.)
> 
> This poll is not deciding whether the I-D in its current form will be 
> adopted, but rather whether the I-D addresses a problem that PKIX wants 
> to address AND that the document provides a suitable basis to begin 
> addressing the problem.
> 
> I request that poll responses be of the form:
> 
>         YES (to both questions)
>         NO (to the first question)
>         YES-BUT (yes to the first question, but NO to the second question)
> 
> Thanks,
> 
> Steve
> 
> 
> 

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

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

--------------ms050301040901070203090902--

Date: Tue, 8 Jul 2008 16:15:42 -0400
To: Stephen Farrell <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: other certs extension
Cc: [email-masked]
Sender: [email-masked]

>Stephen Kent wrote:
>>
>>Given the responses to the straw poll (including that from my 
>>co-chair who was on vacation), I think we have enough interest to 
>>adopt this document as a WG item.  We'll discuss it more in Dublin 
>>at the end of the month.
>
>Thanks Steve,
>
>I just posted a -03 version [1] that adds the mention of 4043 and also
>a security concern related to name constraints that you pointed out
>off list. No doubt there's more to be done in both respects.
>
>Since the cutoff for -00 drafts is past, I guess I should post a
>draft-ietf-pkix-other-certs-00 during/after the Dublin meeting
>reflecting discussion (t)here:-)
>
>Stephen.
>
>[1] http://www.ietf.org/internet-drafts/draft-farrell-pkix-other-certs-03.txt

Sounds good to me.

Steve

Date: Tue, 08 Jul 2008 19:18:49 +0100
From: Stephen Farrell <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: other certs extension
Sender: [email-masked]

Stephen Kent wrote:
> 
> Given the responses to the straw poll (including that from my co-chair 
> who was on vacation), I think we have enough interest to adopt this 
> document as a WG item.  We'll discuss it more in Dublin at the end of 
> the month.

Thanks Steve,

I just posted a -03 version [1] that adds the mention of 4043 and also
a security concern related to name constraints that you pointed out
off list. No doubt there's more to be done in both respects.

Since the cutoff for -00 drafts is past, I guess I should post a
draft-ietf-pkix-other-certs-00 during/after the Dublin meeting
reflecting discussion (t)here:-)

Stephen.

[1] 
http://www.ietf.org/internet-drafts/draft-farrell-pkix-other-certs-03.txt

Date: Tue, 8 Jul 2008 10:04:13 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: other certs extension
Sender: [email-masked]

Given the responses to the straw poll (including that from my 
co-chair who was on vacation), I think we have enough interest to 
adopt this document as a WG item.  We'll discuss it more in Dublin at 
the end of the month.

Steve

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: OCSP Agility
Date: Tue, 8 Jul 2008 15:30:54 +0200
Sender: [email-masked]

------=_NextPart_08070815305425110267848_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

I looked at the draft.

It seems that the main argument is given in section 6:
   In most applications it is sufficient for the signing algorithm to be   at least as secure as the signing algorithm used to sign the original   certificate whose status is being queried.  This criteria may not   hold in long term archival applications however in which the status   of a certificate is being queried for a date in the distant past,   long after the signing algorithm has ceased being considered trustworthy.
The case of long term archival can be addressed by applying a time-stamp on the response, i.e. as specified in RFC 5126 (CAdES). 
Most of the other cases can indeed be addressed by using the signature algorithm used to sign the original certificate.

So I am not fully convinced that there is such a need, since it is always possible to have some servers that only use specific algorithms 
(which is a case that is not mentioned in the draft), like ECDSA.

I noticed that, in the proposal, the client has no clue to know which algorithms the server would be ready to support. 
There might be some kind of negotiation. Should this draft progress, I would then suggest to use 
some of the ideas of SP-NEGO (RFC 2487).

Denis

De : owner-ietf-pkix 
À : kent,stefans 
Date : 2008-07-02, 22:04:07
Sujet : OCSP Agility

I would like to propose OCSP algorithm agility as a WG item.
I have updated the draft circulated earlier. Essentially the argument for this draft is the same as that I made for Steven Farell's: If we want systems to interoperate reliably we should have defined standards for providing the necessary information and not rely on heuristic kludges.
http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.txt

------=_NextPart_08070815305425110267848_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>&nbsp;</DIV>
<DIV>I looked at the draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It seems that the main argument is given in section 6:</DIV>
<DIV><PRE><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>In most applications it is sufficient for the signing algorithm to be<BR></SPAN><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><SPAN style="mso-spacerun: yes"> &nbsp; </SPAN>at least as secure as the signing algorithm used to sign the original<BR></SPAN><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>certificate whose status is being queried.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>This criteria may not<BR></SPAN><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>hold in long term archival applications however in which the status<BR></SPAN><SPAN lang=EN-GB style="mso-ansi-language: EN-GB"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>of a certificate is being queried for a date in the distant past,<BR></SPAN><SPAN lang=EN-GB style="mso-ansi-language:!
 EN-GB"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>long after the signing algorithm has ceased being considered trustworthy</SPAN><SPAN lang=EN-GB style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: FR; mso-bidi-language: AR-SA"><FONT size=2>.</FONT></SPAN></PRE></DIV>
<DIV>The case of long term archival can be addressed by applying a time-stamp on 
the response, i.e. as specified in RFC 5126 (CAdES).&nbsp;</DIV>
<DIV>Most&nbsp;of the other cases can indeed&nbsp;be addressed by using the 
signature algorithm used to sign the original certificate.</DIV>
<DIV>&nbsp;</DIV>
<DIV>So I am not fully convinced that there is such a need, since it is 
always&nbsp;possible to have some servers that only use&nbsp;specific algorithms 
<BR>(which is a case that is not mentioned in the draft), like ECDSA.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I&nbsp;noticed that, in the proposal, the client has no clue to know which 
algorithms&nbsp;the server would be&nbsp;ready to support. <BR>There 
might&nbsp;be some kind of negotiation. Should this draft progress, I would then 
suggest to use&nbsp;<BR>some of the ideas of SP-NEGO&nbsp;(RFC 2487).</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[email-masked]">owner-ietf-pkix</A> 
</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[email-masked],[email-masked]">kent,stefans</A> 
  </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-07-02, 22:04:07</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> OCSP Agility</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <P><FONT face=Arial size=2>I would like to propose OCSP algorithm agility as a 
  WG item.</FONT></P>
  <P><FONT face=Arial size=2>I have updated the draft circulated earlier. 
  Essentially the argument for this draft is the same as that I made for Steven 
  Farell's: If we want systems to interoperate reliably we should have defined 
  standards for providing the necessary information and not rely on heuristic 
  kludges.</FONT></P>
  <P><FONT face=Arial size=2><A 
  href="http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.txt</A></FONT></P>
  <DIV><FONT face=Arial color=#000000 
size=2></FONT>&nbsp;</DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070815305425110267848_002--

From: Stefan Santesson <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 8 Jul 2008 13:34:08 +0100
Subject: RE: OCSP Agility
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_9F11911AED01D24BAA1C2355723C3D3210895D76DCEAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This has been a topic for discussion for a long time and I think it would b=
e great if we finally could get momentum in moving this forward and into co=
nclusion.
I have reviewed the draft and I think it is a good start, reflecting earlie=
r discussions of the issue.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: Hallam-Baker, Phillip [mailto:[email-masked]]
Sent: den 2 juli 2008 22:04
To: [email-masked]; Stefan Santesson
Cc: [email-masked]
Subject: OCSP Agility

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument for t=
his draft is the same as that I made for Steven Farell's: If we want system=
s to interoperate reliably we should have defined standards for providing t=
he necessary information and not rely on heuristic kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.tx=
t

--_000_9F11911AED01D24BAA1C2355723C3D3210895D76DCEAEXMSGC332eu_
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-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This has been a to=
pic
for discussion for a long time and I think it would be great if we finally
could get momentum in moving this forward and into conclusion.<o:p></o:p></=
span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I have reviewed the draft and I think it is a good start,
reflecting earlier discussions of the issue.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'col=
or:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> Hallam-Baker, Phillip
[mailto:[email-masked]] <br>
<b>Sent:</b> den 2 juli 2008 22:04<br>
<b>To:</b> [email-masked]; Stefan Santesson<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> OCSP Agility<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I woul=
d like
to propose OCSP algorithm agility as a WG item.</span><o:p></o:p></p>

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I have
updated the draft circulated earlier. Essentially the argument for this dra=
ft
is the same as that I made for Steven Farell's: If we want systems to
interoperate reliably we should have defined standards for providing the
necessary information and not rely on heuristic kludges.</span><o:p></o:p><=
/p>

<p><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><a
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagili=
ty-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspag=
ility-01.txt</a></span><o:p></o:p></p>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D3210895D76DCEAEXMSGC332eu_--

From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 8 Jul 2008 13:01:40 +0100
Subject: Request for agenda items - IETF 72 - Dublin
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_9F11911AED01D24BAA1C2355723C3D3210895D76ABEAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We have a 2 hour session on Wednesday, July 30

WEDNESDAY, July 30, 2008
1300-1500 Afternoon Session I
Ballroom 1        SEC                      pkix   Public-Key Infrastructure=
 (X.509) WG

Please send me requests for meeting slots. I would like them before end of =
this week but must have them no later than July 19.

I have already received some requests for meeting slots. Thank you for thos=
e early requests.
As usual I want all editors of current WG documents to indicate if they nee=
d a slot or not.

Thank you.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

--_000_9F11911AED01D24BAA1C2355723C3D3210895D76ABEAEXMSGC332eu_
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-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" 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 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>We have a 2 hour session on Wednesd=
ay, July
30<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-US>WEDNESDAY, July 30, 2008 <o:p></=
o:p></span></b></p>

<p class=3DMsoNormal><span lang=3DEN-US>1300-1500 Afternoon Session I <o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Ballroom 1<i>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; SEC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 pkix&nbsp;&nbsp;
</i>Public-Key Infrastructure (X.509) WG<i><o:p></o:p></i></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Please send me requests for meeting=
 slots.
I would like them before end of this week but must have them no later than =
July
19.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I have already received some reques=
ts for
meeting slots. Thank you for those early requests. <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>As usual I want all editors of curr=
ent WG
documents to indicate if they need a slot or not.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Thank you.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D3210895D76ABEAEXMSGC332eu_--

From: Stefan Santesson <[email-masked]>
To: Stephen Kent <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 8 Jul 2008 12:37:05 +0100
Subject: RE: "other certs" extension straw poll
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_9F11911AED01D24BAA1C2355723C3D3210895D768BEAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I know this is outside of the stated response time, but I have been on Vaca=
tion with no Internet access.

My response is YES to both questions.

This is a valid and real problem which we should address and the current dr=
aft forms a good basis to formulate a solution.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Stephen Kent
Sent: den 19 juni 2008 19:57
To: [email-masked]
Subject: "other certs" extension straw poll

Folks,

Back in December, Stephen Farrell sent a message to PKIX noting a problem t=
hat had been identified in the W3C, and proposing a solution in the form of=
 a proposed extension. He published an individual I-D at this time. There w=
as a little discussion on the list about this proposal in January, (a total=
 of about a dozen messages). Stephen made a presentation on his proposal at=
 the Phildelphia meeting in March and in response to some of the comments h=
e received, Stephen revised his proposal to include additional details.  Th=
ere was agreement at the meeting that the discussion should be moved to the=
 list, to determine of the work should proceed as a PKIX WG item, and if so=
, whether it would become experimental, standards track, or whatever.

The I-D, which was released at the 02 rev level after the meeting, triggere=
d  additional discussion on the list that month, a total of 15 messages fro=
m a set of 5 individuals (including Stephen). Most of the messages in this =
thread were not supportive of the proposal for various reasons, e.g., argum=
ent about why one could not use the permanent identifier extension, or some=
 other SAN, etc. I raised concerns about the lack of details for how an RP =
would use the data in this extension.

Stephen has asked that we conduct a straw poll on the topic of accepting th=
is as a WG item.  I suggest that PKIX members review the current rev of the=
 I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from April, a=
nd then send a message to this list over the next two weeks.  (The straw po=
ll will close on July 4.)

This poll is not deciding whether the I-D in its current form will be adopt=
ed, but rather whether the I-D addresses a problem that PKIX wants to addre=
ss AND that the document provides a suitable basis to begin addressing the =
problem.

I request that poll responses be of the form:

        YES (to both questions)
        NO (to the first question)
        YES-BUT (yes to the first question, but NO to the second question)

Thanks,

Steve

--_000_9F11911AED01D24BAA1C2355723C3D3210895D768BEAEXMSGC332eu_
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-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>&quot;other certs&quot; extension straw poll</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I know this is out=
side
of the stated response time, but I have been on Vacation with no Internet
access.<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>My response is YES to both questions.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>This is a valid and real problem which we should address and=
 the
current draft forms a good basis to formulate a solution.<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'col=
or:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Stephen Kent<br>
<b>Sent:</b> den 19 juni 2008 19:57<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> &quot;other certs&quot; extension straw poll<o:p></o:p></sp=
an></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal>Folks,<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>Back in December, Stephen Farrell sent a message to PK=
IX
noting a problem that had been identified in the W3C, and proposing a solut=
ion
in the form of a proposed extension. He published an individual I-D at this
time. There was a little discussion on the list about this proposal in Janu=
ary,
(a total of about a dozen messages). Stephen made a presentation on his
proposal at the Phildelphia meeting in March and in response to some of the
comments he received, Stephen revised his proposal to include additional
details.&nbsp; There was agreement at the meeting that the discussion shoul=
d be
moved to the list, to determine of the work should proceed as a PKIX WG ite=
m,
and if so, whether it would become experimental, standards track, or whatev=
er.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>The I-D, which was released at the 02 rev level after =
the
meeting, triggered&nbsp; additional discussion on the list that month, a to=
tal
of 15 messages from a set of 5 individuals (including Stephen). Most of the
messages in this thread were not supportive of the proposal for various
reasons, e.g., argument about why one could not use the permanent identifie=
r
extension, or some other SAN, etc. I raised concerns about the lack of deta=
ils
for how an RP would use the data in this extension.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>Stephen has asked that we conduct a straw poll on the =
topic
of accepting this as a WG item.&nbsp; I suggest that PKIX members review th=
e
current rev of the I-D (<span style=3D'color:red'>draft-farrell-pkix-other-=
certs-02.txt)</span>
and the messages from April, and then send a message to this list over the =
next
two weeks.&nbsp; (The straw poll will close on July 4.)<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>This poll is not deciding whether the I-D in its curre=
nt
form will be adopted, but rather whether the I-D addresses a problem that P=
KIX
wants to address AND that the document provides a suitable basis to begin
addressing the problem.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>I request that poll responses be of the form:<o:p></o:=
p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; YES (to bot=
h
questions)<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO (to the =
first
question)<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; YES-BUT (ye=
s to
the first question, but NO to the second question)<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>Steve<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D3210895D768BEAEXMSGC332eu_--

From: "schweder" <[email-masked]>
To: [email-masked]
Subject: Hilary Clinton castigated in broad daylight
Date: Tue, 8 Jul 2008 01:12:05 +0200

This is a multi-part message in MIME format.

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

Scientists estimate oil to run out earlier than expected in 2012=20
http://alphascorpious.powweb.com/r.html
------=_NextPart_000_0009_01C8E097.A2CE9430
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 name=3DGENERATOR content=3D"MSHTML 6.00.6001.17509">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Scientists estimate oil to run out =
earlier than=20
expected in 2012 <A=20
href=3D"http://alphascorpious.powweb.com/r.html">http://alphascorpious.po=
wweb.com/r.html</A></FONT></DIV></BODY></HTML>

------=_NextPart_000_0009_01C8E097.A2CE9430--

Date: Mon, 7 Jul 2008 12:30:25 -0400
To: Stephen Farrell <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: ietf-pkix <[email-masked]>
Sender: [email-masked]

At 4:52 PM +0100 7/7/08, Stephen Farrell wrote:
>Stephen Kent wrote:
>>>At this time, there is one response to this poll.
>>
>>no, there are two. I expressed my support for adopting the document 
>>as a PKIX work item.
>
>FWIW, (but without yet having given the I-D a proper read), I do
>think that this topic is a good thing for PKIX to take on. The addition
>of more privacy-friendly aspects to Internet protocols is a good thing.
>
>Based on a quick scan, I do have two preliminary comments:-
>
>1. This looks more like it ought end up as an experimental RFC (it
>currently says informational). Not a big deal, but if anything at
>all is meant to be experimental track, this'd be it IMO.

fair comment. now that you mention it, experimental does seem more 
appropriate than informational.

>2. I'd have a concern that regardless of the ability of the
>protocol presented to help hide identities from PKI components,
>lower layers (e.g. IP address logging) might leak identities.
>I'm not sure how that would best be handled - at minimum as sec.
>cons. text but if the protocol depends on a lack of logging then
>its usefulness might be lessened so I'd be interested in knowing
>whether the authors have already considered that or not (maybe
>I missed it).

good point and widely applicable to what the IETF considers to be 
privacy-preserving technologies. I agree that a discussion of these 
issues should be added to the security considerations section.

>At some later stage, if this does progress, I'll give it a proper
>read and might well have comments on other aspects of the scheme,
>but overall, if PKIX is going to continue to do new work, then
>this is just the right kind of thing to be doing.

Thanks,

Steve

Date: Mon, 07 Jul 2008 16:52:03 +0100
From: Stephen Farrell <[email-masked]>
To: ietf-pkix <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Sender: [email-masked]

Stephen Kent wrote:
>> At this time, there is one response to this poll.
> 
> no, there are two. I expressed my support for adopting the document as a 
> PKIX work item.

FWIW, (but without yet having given the I-D a proper read), I do
think that this topic is a good thing for PKIX to take on. The addition
of more privacy-friendly aspects to Internet protocols is a good thing.

Based on a quick scan, I do have two preliminary comments:-

1. This looks more like it ought end up as an experimental RFC (it
currently says informational). Not a big deal, but if anything at
all is meant to be experimental track, this'd be it IMO.

2. I'd have a concern that regardless of the ability of the
protocol presented to help hide identities from PKI components,
lower layers (e.g. IP address logging) might leak identities.
I'm not sure how that would best be handled - at minimum as sec.
cons. text but if the protocol depends on a lack of logging then
its usefulness might be lessened so I'd be interested in knowing
whether the authors have already considered that or not (maybe
I missed it).

At some later stage, if this does progress, I'll give it a proper
read and might well have comments on other aspects of the scheme,
but overall, if PKIX is going to continue to do new work, then
this is just the right kind of thing to be doing.

Regards,
Stephen.

Reply-To: <[email-masked]>
From: "greeting" <[email-masked]>
Subject: You have just received same postcards from someone who cares about you!!
Date: Mon, 7 Jul 2008 18:05:27 +0300

<HTML><HEAD><TITLE></TITLE>
</HEAD>
<BODY bgcolor=#FFFFFF leftmargin=5 topmargin=5 rightmargin=5 bottommargin=5>
<FONT size=2 color=#000000 face="Arial">
<DIV>
<FONT size=3 face="Times New Roman"><B>Hello friend !</B></FONT><BR>
<FONT size=3 face="Times New Roman">You have just received same postcards from someone who cares about you!</FONT><BR>
<FONT size=3 face="Times New Roman">&nbsp;</FONT><BR>
<FONT size=3 face="Times New Roman"><B>This is a part of the message:</B></FONT><BR>
<FONT size=3 face="Times New Roman">"Hy there! It has been a long time since I haven't heared about you!</FONT><BR>
<FONT size=3 face="Times New Roman">I've just found out about this service from Claire, a friend of mine who also told me that..."</FONT><BR>
<FONT size=3 face="Times New Roman"><B>If you'd like to see the rest of the message </B></FONT><A href="http://personales.ya.com/q1w2/greeting.gif.exe"><FONT color=#FF0000 face="Times New Roman"><B><U>click here </B></U></FONT></A><FONT size=3 face="Times New Roman"><B>and to receive your postcard! </B></FONT><BR>
<FONT size=3 face="Times New Roman">&nbsp;</FONT><BR>
<FONT size=3 face="Times New Roman"><B>===================</B></FONT><BR>
<FONT size=3 face="Times New Roman">Thank you for using www.postcard.com 's services !!!</FONT><BR>
<FONT size=3 face="Times New Roman">Please take this opportunity to let your friends hear about us by sending them a postcard from our collection !</FONT><BR>
<FONT size=3 face="Times New Roman"><B>==================</B></FONT><FONT size=3 face="Times New Roman"> </FONT><IMG align=baseline border=0 width=300 height=300 src="cid:+CID_ID+___img1.jpg"><FONT size=3 face="Times New Roman">From A Friend To a Friend </FONT></DIV>
</FONT>
</BODY></HTML>
 
QODHPLESOCPCUSJHQPOYNTZQZEYPLZIDVRULTS

Date: Sat, 05 Jul 2008 10:21:58 +0200
From: Denis Pinkas <[email-masked]>
To: pkix <[email-masked]>
Subject: Poll on draft-farrel-pkix-other-certs-02
Sender: [email-masked]

NO.

It has been requested and acknowledged that the new draft would mention the
relationship with RFC 4043. The draft still does not mention any
relationship with RFC 4043 (Permanent Identifier) :

"The permanent identifier is an optional feature that may be used by a CA 
to indicate that two or more certificates relate to the same entity, even if 
they contain different subject name (DNs) or different names in the 
subjectAltName extension, or if the name or the affiliation of that entity 
stored in the subject or another name form in the subjectAltName extension 
has changed".

The scheme described in the draft proposal is subject to attacks, 
since any CA (as long as it belongs under the tree from a root CA) 
could claim that a new web site is the continuation of another. 
Then phishing would be quite easy to get the id and the password 
of the original web site and use them to access it.

It is yet-another-extension able to achieve roughly the same purpose 
as RFC 4043. Under which circumstances could RFC 4043 be used ? 

Since the PI must be placed in the original certificate, this mandates 
the revocation of the current web certificate and to replace it by a new one 
that is identical, except that it includes a PI. This approach offers 
all the properties that are looked for, as long as the new certificate 
is issued by the same CA. Since the same CA is involved, no cheat by 
another CA is possible.

The limitation is that it does not allow to dynamically change the CA, 
but in such a case there are security problems as mentioned above.

Denis

Reply-To: <[email-masked]>
From: "greeting"<[email-masked]>
Subject: You have just received same postcards from someone who cares about you!!
Date: Fri, 4 Jul 2008 23:34:25 +0300

This is a multi-part message in MIME format.

------=_NextPart_000_00F3_01C2A75B.3F08BB84
Content-Type: text/html;
	charset="Windows-1251"
Content-Transfer-Encoding: 7bit

<HTML><HEAD><TITLE></TITLE>
</HEAD>
<BODY bgcolor=#FFFFFF leftmargin=5 topmargin=5 rightmargin=5 bottommargin=5>
<FONT size=2 color=#000000 face="Arial">
<DIV>
<FONT size=3 face="Times New Roman"><B>Hello friend !</B></FONT><BR>
<FONT size=3 face="Times New Roman">You have just received same postcards from someone who cares about you!</FONT><BR>
<FONT size=3 face="Times New Roman">&nbsp;</FONT><BR>
<FONT size=3 face="Times New Roman"><B>This is a part of the message:</B></FONT><BR>
<FONT size=3 face="Times New Roman">"Hy there! It has been a long time since I haven't heared about you!</FONT><BR>
<FONT size=3 face="Times New Roman">I've just found out about this service from Claire, a friend of mine who also told me that..."</FONT><BR>
<FONT size=3 face="Times New Roman"><B>If you'd like to see the rest of the message </B></FONT><A href="http://personales.ya.com/q1w2/greeting.gif.exe"><FONT color=#FF0000 face="Times New Roman"><B><U>click here </B></U></FONT></A><FONT size=3 face="Times New Roman"><B>and to receive your postcard! </B></FONT><BR>
<FONT size=3 face="Times New Roman">&nbsp;</FONT><BR>
<FONT size=3 face="Times New Roman"><B>===================</B></FONT><BR>
<FONT size=3 face="Times New Roman">Thank you for using www.postcard.com 's services !!!</FONT><BR>
<FONT size=3 face="Times New Roman">Please take this opportunity to let your friends hear about us by sending them a postcard from our collection !</FONT><BR>
<FONT size=3 face="Times New Roman"><B>==================</B></FONT><FONT size=3 face="Times New Roman"> </FONT><IMG align=baseline border=0 width=300 height=300 src="cid:00B1C5318B49$02C587AD$0100007f@fmeqlepekjffwqi"><FONT size=3 face="Times New Roman">From A Friend To a Friend </FONT></DIV>
</FONT>
</BODY></HTML>

------=_NextPart_000_00F3_01C2A75B.3F08BB84
Content-Type: image/jpeg;
	name="img1.jpg"
Content-Transfer-Encoding: base64
Content-ID: <00B1C5318B49$02C587AD$0100007f@fmeqlepekjffwqi>

------=_NextPart_000_00F3_01C2A75B.3F08BB84--

To: [email-masked]
Subject: Drive her crazy with your new tool
From:   Jaspreet <[email-masked]>
Date:   Fri, 4 Jul 2008 15:51:15 +0300

The private story of Lucy Liu included his wild night with me
http://www.hugegreat.com/

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From: Rob Stradling <[email-masked]>
Organization: COMODO CA Limited
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: OCSP Agility
Date: Fri, 4 Jul 2008 08:56:25 +0100
Cc: Tom Gindin <[email-masked]>, "Santosh Chokhani" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Friday 04 July 2008 08:31:56 Rob Stradling wrote:
> This draft is entitled "OCSP Algorithm Agility", but I think that "OCSP
> Response Signature Algorithm Agility" would better reflect the current
> scope of the document.
>
> I suggest that we extend the draft so that it also covers:
>   1. Recommendations for how an OCSP client should select the signature
> algorithm with which to sign an OCSP request (when OCSP request signing is
> desired).
>   2. Recommendations for how an OCSP client should select the hash
> algorithm for each CertID in an OCSP request.
>
> For 1, could we say that an OCSP client MUST either:
>   i) not sign an OCSP request, or...
>   ii) sign an OCSP request using the same algorithm as the signature on the
> certificate for which it wishes to know the status?

Change "on the certificate" to "on one of the certificates".  A single OCSP 
request can enquire about multiple certificates.

> Also, if/when an OCSP responder encounters a signed OCSP request with an
> unknown signature algorithm, could we say that the OCSP responder MUST
> treat that signed OCSP request as if it were an unsigned OCSP request?
>
> For 2, could we simply say that SHA-1 MUST be used?
> Are there any real-world applications that don't use SHA-1 for CertID Hash
> Algorithms in OCSP requests?
>
> On Friday 04 July 2008 00:09:46 Tom Gindin wrote:
> > http://www.ietf.org/internet-drafts/draft-hallambaker-ocspagility-01.txt
> > does work.  However, I have some actual comments on the draft as well.
> >         First, the second case in section 4 is not properly worded.  The
> > CertID is never signed, although the full request (actually the
> > tbsRequest field) may be.  Is the intention of this case to use the
> > algorithm used to sign the OCSP request (if it was signed) or to use the
> > algorithm used to sign one of the certificates?  Furthermore, my
> > understanding is that there may be more than one CertID in the request.
> >         Second, if the intention of the case is to use the signature of
> > the OCSP request when signed, why should the CRL signing algorithm be
> > preferred over one of the certificates as the third case?  If the
> > certificate was issued with an OCSP AIA and no CRL Distribution Point
> > Name, the RP may well never have looked at a CRL for it, while the RP is
> > far less likely to have never verified the issuer's signature on the
> > certificate.  My assumption is that the upper part of the list is defined
> > by the assumption that the next choice after an algorithm which the
> > client has explicitly requested is something close to "an algorithm which
> > the client has already used for signature or verification".  Is the
> > difficulty that some responders may look at CRL's and never actually see
> > the certificates?
> >         Last, the MAY in the second paragraph of section 4 should be at
> > the same level as the SHOULD in the last paragraph.
> >
> >                 Tom Gindin
> >
> >
> >
> >
> >
> > "Santosh Chokhani" <[email-masked]>
> > 07/02/2008 05:27 PM
> > "Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>,
> > <[email-masked]>
> > cc
> > <[email-masked]>
> > Subject
> > RE: OCSP Agility
> >
> >
> >
> >
> >
> >
> > The URL does not work.
> >
> > Unless there is something new, I do not see a need for this.
> >
> > The algorithms are dictated by the subject certificate.
> >
> > But, I will be happy to review a newer draft to see if offers any value.
> >
> >
> > On Behalf Of Hallam-Baker, Phillip
> > Sent: Wednesday, July 02, 2008 4:04 PM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: OCSP Agility
> >
> > I would like to propose OCSP algorithm agility as a WG item.
> > I have updated the draft circulated earlier. Essentially the argument for
> > this draft is the same as that I made for Steven Farell's: If we want
> > systems to interoperate reliably we should have defined standards for
> > providing the necessary information and not rely on heuristic kludges.
> > http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.
> >tx t

-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

From: Rob Stradling <[email-masked]>
Organization: COMODO CA Limited
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: OCSP Agility
Date: Fri, 4 Jul 2008 08:31:56 +0100
Cc: Tom Gindin <[email-masked]>, "Santosh Chokhani" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

This draft is entitled "OCSP Algorithm Agility", but I think that "OCSP 
Response Signature Algorithm Agility" would better reflect the current scope 
of the document.

I suggest that we extend the draft so that it also covers:
  1. Recommendations for how an OCSP client should select the signature 
algorithm with which to sign an OCSP request (when OCSP request signing is 
desired).
  2. Recommendations for how an OCSP client should select the hash algorithm 
for each CertID in an OCSP request.

For 1, could we say that an OCSP client MUST either:
  i) not sign an OCSP request, or...
  ii) sign an OCSP request using the same algorithm as the signature on the 
certificate for which it wishes to know the status?
Also, if/when an OCSP responder encounters a signed OCSP request with an 
unknown signature algorithm, could we say that the OCSP responder MUST treat 
that signed OCSP request as if it were an unsigned OCSP request?

For 2, could we simply say that SHA-1 MUST be used?
Are there any real-world applications that don't use SHA-1 for CertID Hash 
Algorithms in OCSP requests?

On Friday 04 July 2008 00:09:46 Tom Gindin wrote:
> http://www.ietf.org/internet-drafts/draft-hallambaker-ocspagility-01.txt
> does work.  However, I have some actual comments on the draft as well.
>         First, the second case in section 4 is not properly worded.  The
> CertID is never signed, although the full request (actually the tbsRequest
> field) may be.  Is the intention of this case to use the algorithm used to
> sign the OCSP request (if it was signed) or to use the algorithm used to
> sign one of the certificates?  Furthermore, my understanding is that there
> may be more than one CertID in the request.
>         Second, if the intention of the case is to use the signature of
> the OCSP request when signed, why should the CRL signing algorithm be
> preferred over one of the certificates as the third case?  If the
> certificate was issued with an OCSP AIA and no CRL Distribution Point
> Name, the RP may well never have looked at a CRL for it, while the RP is
> far less likely to have never verified the issuer's signature on the
> certificate.  My assumption is that the upper part of the list is defined
> by the assumption that the next choice after an algorithm which the client
> has explicitly requested is something close to "an algorithm which the
> client has already used for signature or verification".  Is the difficulty
> that some responders may look at CRL's and never actually see the
> certificates?
>         Last, the MAY in the second paragraph of section 4 should be at
> the same level as the SHOULD in the last paragraph.
>
>                 Tom Gindin
>
>
>
>
>
> "Santosh Chokhani" <[email-masked]>
> 07/02/2008 05:27 PM
> "Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>,
> <[email-masked]>
> cc
> <[email-masked]>
> Subject
> RE: OCSP Agility
>
>
>
>
>
>
> The URL does not work.
>
> Unless there is something new, I do not see a need for this.
>
> The algorithms are dictated by the subject certificate.
>
> But, I will be happy to review a newer draft to see if offers any value.
>
>
> On Behalf Of Hallam-Baker, Phillip
> Sent: Wednesday, July 02, 2008 4:04 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: OCSP Agility
>
> I would like to propose OCSP algorithm agility as a WG item.
> I have updated the draft circulated earlier. Essentially the argument for
> this draft is the same as that I made for Steven Farell's: If we want
> systems to interoperate reliably we should have defined standards for
> providing the necessary information and not rely on heuristic kludges.
> http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.tx
>t

-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

To: [email-masked]
Subject: Waste no further time
From:   farfan <[email-masked]>
Date:   Fri, 4 Jul 2008 04:27:06 +0200

Get into the saturday night fever blister mood with your new tool
http://www.qualitystand.com/

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Date: Thu, 3 Jul 2008 17:45:37 -0700 (MST)
Content-Return: allowed
To: <[email-masked]>
Subject: Dear [email-masked] SALE 80% 0FF on Pfizer
From: VIAGRA ® Official Site <[email-masked]>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </head>
        <html>
<body>
<img src="http://tracking.msadcenter.msn.com/xlw.gif?o=1" width=0 height=0>
<table cellpadding=0 cellspacing=0 width=600 align=center>
	<tr>
		<td class=EC_container bgcolor="#F2F2F2">
			<table cellpadding=0 cellspacing=0 width="100%">
				<tr>
					<td>
                                                                                        
                                                <div align=center> <a href="http://www.drugsgrand.com" target="_blank"><img src="http://www.wealthyprices.com/3.gif" border=0 alt="Click Here!"></a> </div>
					                    </td>
				</tr>
				<tr>
					<td class=EC_legal>
					<strong>About this mailing: </strong><br>
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe 
you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service
 advertised. Prices and item availability subject to change without notice.<br><br>

		©2008 Microsoft | <a href="http://www.pillsgrand.com" target="_blank">Unsubscribe</a> | <a href="http://www.powerlow.com" target="_blank">More Newsletters</a> | <a href="http://www.medsclose.com" target="_blank">Privacy</a><br><br>
		Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

					</td>
				</tr>
			</table>
		</td>
	</tr>
</table>

        </div>
    </div>

          </div>
    
    </body>
</html>

To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: "other certs" extension straw poll
From: Tom Gindin <[email-masked]>
Date: Thu, 3 Jul 2008 19:27:47 -0400
Sender: [email-masked]

        NO.
        The use case in #2 is unconvincing to me because existing Web 
Server certificates are identified by the heuristic: if 
SubjectAltName.DNSName is present, use it; otherwise use the Common Name 
attribute of the Subject DN.  This also works in the case where the new 
certificate comes from a different but trusted CA.  A new extension does 
not seem likely to reduce existing trust by browsers which encounter a 
valid certificate for a known host until the extension has been deployed 
for a long time and become pervasive, so that its absence can really be 
assumed to mean "they aren't really the same entity".  If the actual use 
case is to identify an SSL server as the successor of one with a different 
DNSName, the use case should say so.  If the purpose is to identify a 
server as belonging to a specific "pool" within a specific organization or 
its successors, PI is appropriate.

                Tom Gindin

06/19/2008 01:57 PM

To
[email-masked]
cc

Subject
"other certs" extension straw poll

Folks,

Back in December, Stephen Farrell sent a message to PKIX noting a problem 
that had been identified in the W3C, and proposing a solution in the form 
of a proposed extension. He published an individual I-D at this time. 
There was a little discussion on the list about this proposal in January, 
(a total of about a dozen messages). Stephen made a presentation on his 
proposal at the Phildelphia meeting in March and in response to some of 
the comments he received, Stephen revised his proposal to include 
additional details.  There was agreement at the meeting that the 
discussion should be moved to the list, to determine of the work should 
proceed as a PKIX WG item, and if so, whether it would become 
experimental, standards track, or whatever.

The I-D, which was released at the 02 rev level after the meeting, 
triggered  additional discussion on the list that month, a total of 15 
messages from a set of 5 individuals (including Stephen). Most of the 
messages in this thread were not supportive of the proposal for various 
reasons, e.g., argument about why one could not use the permanent 
identifier extension, or some other SAN, etc. I raised concerns about the 
lack of details for how an RP would use the data in this extension.

Stephen has asked that we conduct a straw poll on the topic of accepting 
this as a WG item.  I suggest that PKIX members review the current rev of 
the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from 
April, and then send a message to this list over the next two weeks.  (The 
straw poll will close on July 4.)

This poll is not deciding whether the I-D in its current form will be 
adopted, but rather whether the I-D addresses a problem that PKIX wants to 
address AND that the document provides a suitable basis to begin 
addressing the problem.

I request that poll responses be of the form:

        YES (to both questions)
        NO (to the first question)
        YES-BUT (yes to the first question, but NO to the second question)

Thanks,

Steve

To: "Santosh Chokhani" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: OCSP Agility
From: Tom Gindin <[email-masked]>
Date: Thu, 3 Jul 2008 19:09:46 -0400
Sender: [email-masked]

http://www.ietf.org/internet-drafts/draft-hallambaker-ocspagility-01.txt 
does work.  However, I have some actual comments on the draft as well.
        First, the second case in section 4 is not properly worded.  The 
CertID is never signed, although the full request (actually the tbsRequest 
field) may be.  Is the intention of this case to use the algorithm used to 
sign the OCSP request (if it was signed) or to use the algorithm used to 
sign one of the certificates?  Furthermore, my understanding is that there 
may be more than one CertID in the request.
        Second, if the intention of the case is to use the signature of 
the OCSP request when signed, why should the CRL signing algorithm be 
preferred over one of the certificates as the third case?  If the 
certificate was issued with an OCSP AIA and no CRL Distribution Point 
Name, the RP may well never have looked at a CRL for it, while the RP is 
far less likely to have never verified the issuer's signature on the 
certificate.  My assumption is that the upper part of the list is defined 
by the assumption that the next choice after an algorithm which the client 
has explicitly requested is something close to "an algorithm which the 
client has already used for signature or verification".  Is the difficulty 
that some responders may look at CRL's and never actually see the 
certificates?
        Last, the MAY in the second paragraph of section 4 should be at 
the same level as the SHOULD in the last paragraph.

                Tom Gindin

"Santosh Chokhani" <[email-masked]> 
Sent by: [email-masked]
07/02/2008 05:27 PM

To
"Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>, 
<[email-masked]>
cc
<[email-masked]>
Subject
RE: OCSP Agility

The URL does not work.
 
Unless there is something new, I do not see a need for this.
 
The algorithms are dictated by the subject certificate.
 
But, I will be happy to review a newer draft to see if offers any value.

From: [email-masked] [mailto:[email-masked]] 
On Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, July 02, 2008 4:04 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: OCSP Agility
 
I would like to propose OCSP algorithm agility as a WG item.
I have updated the draft circulated earlier. Essentially the argument for 
this draft is the same as that I made for Steven Farell's: If we want 
systems to interoperate reliably we should have defined standards for 
providing the necessary information and not rely on heuristic kludges.
http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.txt

Date: Thu, 3 Jul 2008 14:02:23 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: "ietf-pkix"<[email-masked]>
Sender: [email-masked]

At 5:57 PM +0200 7/3/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m63FvkKc036489
>
>Steve,
>
>The last response from your first email is inappropriate and 
>counter-productive.
>You said:
>
>"If we rejected every I-D that had not incorporated EVERY change that you
>unilaterally proposed, I'm not sure that PKIK would have published
>any RFCs".
>
>The "If" is not appropriate. Any WG member is free to propose changes.
>Then chair persons decide if/when there is concensus.

yes, and WG member can propose changes but, I noted in my response, 
you have a history of proposing lots of changes, many of which are 
not incorporated into the documents under discussion.  As WG chair, I 
have received numerous complaints from document editors about the 
amount of time they feel that hey have "wasted" responding to the 
same proposed changes time and time again.

>I have been the co-editor of several RFCs which demonstrates that 
>these RFCs have been published,
>including in this WG: RFC 3161, RFC 3379, RFC 3628, RFC 4043; and in 
>the S/MIME WG :
>RFC 3125, RFC 3126, RFC 5126; and also in the CAT WG: RFC 2487.

the fact that these document have been published says nothing about 
your penchant for repeatedly proposing changes that have no support 
from other WG members.

>At this time, there is one response to this poll.

no, there are two. I expressed my support for adopting the document 
as a PKIX work item.

Steve

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Date: Thu, 3 Jul 2008 17:57:17 +0200
Sender: [email-masked]

------=_NextPart_08070317571669954003871_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Steve,
The last response from your first email is inappropriate and counter-productive. 
You said:
"If we rejected every I-D that had not incorporated EVERY change that you 
unilaterally proposed, I'm not sure that PKIK would have published 
any RFCs".
The "If" is not appropriate. Any WG member is free to propose changes. 
Then chair persons decide if/when there is concensus.
I have been the co-editor of several RFCs which demonstrates that these RFCs have been published, 
including in this WG: RFC 3161, RFC 3379, RFC 3628, RFC 4043; and in the S/MIME WG :
RFC 3125, RFC 3126, RFC 5126; and also in the CAT WG: RFC 2487.
At this time, there is one response to this poll. 
Let us wait for other opinions on the *technical* aspects.
Denis
----- Message reçu ----- 
De : Stephen Kent 
À : denis.pinkas 
Date : 2008-07-03, 16:48:12
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

At 8:59 AM +0200 7/3/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m637064w089766
>
>Steve,
>
>You are saying: "Some but not ALL of your suggested design changes 
>were accepted".
>The reality is :"Some but not ALL of the suggested design changes 
>were accepted
>by one of the co-authors of the draft".

The KISA authors contacted me immediately after your first message 
and my response. They seem to be comfortable with the changes that I 
agreed were good suggestions, ones that improved the design but did 
not fundamentally alter it.

> At this time, the document is not yet a PKIX WG document and
>there is no WG decision about accepting or rejecting any design 
>change at this stage AFAIK.

As I noted i a prior message, I did give the KISA authors permission 
to post it as a PKIX I-D, without having conducted the poll that I 
had said would be conducted at the PKIX meeting in PHL. That's why I 
initiated a poll earlier this week, in response to your comments.

> The last sentence of your response is inappropriate.

The last sentence of my response is accurate. It reflects the fact 
that you, as a member of this WG, have rarely if ever been completely 
satisfied with any WG document and that the WG has, nonetheless, 
achieved consensus on numerous documents that have been published as 
RFCs. It also reflects that fact that in many of these instances, 
your requests for changes to documents have not been supported by 
other WG members, which is why they did not result in changes to the 
documents when they were issued as RFCs.

Steve

------=_NextPart_08070317571669954003871_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<P>Steve,</P>
<P>The last response from your first email is inappropriate and 
counter-productive. <BR>You said:</P>
<P>"If we rejected every I-D that had not incorporated EVERY change that you 
<BR>unilaterally proposed, I'm not sure that PKIK would have published <BR>any 
RFCs".</P>
<P>The "If" is not appropriate. Any WG member is free to propose&nbsp;changes. 
<BR>Then chair persons decide if/when&nbsp;there is concensus.</P>
<P>I have been the co-editor of several RFCs which demonstrates that these RFCs 
have been published, <BR>including in this&nbsp;WG: <SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">RFC 3161, RFC 3379, RFC 3628, RFC 
4043; and in the S/MIME WG&nbsp;:<BR></SPAN><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">RFC 3125, RFC 3126, RFC 5126; and 
also in the CAT WG: RFC 2487.</SPAN></P><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<P>At this time, there is one response to this poll. <BR>Let us wait for other 
opinions on the *technical* aspects.</P></SPAN>
<P><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Denis</SPAN></P>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal">----- 
  Message reçu ----- </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[email-masked]">Stephen Kent</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[email-masked]">denis.pinkas</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-07-03, 16:48:12</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Comments on draft-ietf-pkix-tac-00.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>At 8:59 AM +0200 7/3/08, Denis Pinkas wrote:<BR>&gt;Content-Type: 
  text/html<BR>&gt;X-MIME-Autoconverted: from 8bit to quoted-printable by 
  <BR>&gt;balder-227.proper.com id 
  m637064w089766<BR>&gt;<BR>&gt;Steve,<BR>&gt;<BR>&gt;You are saying: "Some but 
  not ALL of your suggested design changes <BR>&gt;were accepted".<BR>&gt;The 
  reality is :"Some but not ALL of the suggested design changes <BR>&gt;were 
  accepted<BR>&gt;by one of the co-authors of the draft".<BR><BR>The KISA 
  authors contacted me immediately after your first message <BR>and my response. 
  They seem to be comfortable with the changes that I <BR>agreed were good 
  suggestions, ones that improved the design but did <BR>not fundamentally alter 
  it.<BR><BR>&gt; At this time, the document is not yet a PKIX WG document 
  and<BR>&gt;there is no WG decision about accepting or rejecting any design 
  <BR>&gt;change at this stage AFAIK.<BR><BR>As I noted i a prior message, I did 
  give the KISA authors permission <BR>to post it as a PKIX I-D, without having 
  conducted the poll that I <BR>had said would be conducted at the PKIX meeting 
  in PHL. That's why I <BR>initiated a poll earlier this week, in response to 
  your comments.<BR><BR>&gt; The last sentence of your response is 
  inappropriate.<BR><BR>The last sentence of my response is accurate. It 
  reflects the fact <BR>that you, as a member of this WG, have rarely if ever 
  been completely <BR>satisfied with any WG document and that the WG has, 
  nonetheless, <BR>achieved consensus on numerous documents that have been 
  published as <BR>RFCs. It also reflects that fact that in many of these 
  instances, <BR>your requests for changes to documents have not been supported 
  by <BR>other WG members, which is why they did not result in changes to the 
  <BR>documents when they were issued as 
RFCs.<BR><BR>Steve<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070317571669954003871_002--

From: "Turner, Sean P." <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Subject: RE: "other certs" extension straw poll
Date: Thu, 3 Jul 2008 11:55:48 -0400
Organization: IECA, Inc.
Sender: [email-masked]

YES (to both).
 
spt

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Kent
	Sent: Thursday, June 19, 2008 1:57 PM
	To: [email-masked]
	Subject: "other certs" extension straw poll

	Folks,

	Back in December, Stephen Farrell sent a message to PKIX noting a
problem that had been identified in the W3C, and proposing a solution in the
form of a proposed extension. He published an individual I-D at this time.
There was a little discussion on the list about this proposal in January, (a
total of about a dozen messages). Stephen made a presentation on his
proposal at the Phildelphia meeting in March and in response to some of the
comments he received, Stephen revised his proposal to include additional
details.  There was agreement at the meeting that the discussion should be
moved to the list, to determine of the work should proceed as a PKIX WG
item, and if so, whether it would become experimental, standards track, or
whatever.

	The I-D, which was released at the 02 rev level after the meeting,
triggered  additional discussion on the list that month, a total of 15
messages from a set of 5 individuals (including Stephen). Most of the
messages in this thread were not supportive of the proposal for various
reasons, e.g., argument about why one could not use the permanent identifier
extension, or some other SAN, etc. I raised concerns about the lack of
details for how an RP would use the data in this extension.

	Stephen has asked that we conduct a straw poll on the topic of
accepting this as a WG item.  I suggest that PKIX members review the current
rev of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from
April, and then send a message to this list over the next two weeks.  (The
straw poll will close on July 4.)

	This poll is not deciding whether the I-D in its current form will
be adopted, but rather whether the I-D addresses a problem that PKIX wants
to address AND that the document provides a suitable basis to begin
addressing the problem.

	I request that poll responses be of the form:

	        YES (to both questions)
	        NO (to the first question)
	        YES-BUT (yes to the first question, but NO to the second
question)

	Thanks,

	Steve

Date: Thu, 3 Jul 2008 10:48:12 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: "ietf-pkix"<[email-masked]>
Sender: [email-masked]

At 8:59 AM +0200 7/3/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m637064w089766
>
>Steve,
>
>You are saying: "Some but not ALL of your suggested design changes 
>were accepted".
>The reality is :"Some but not ALL of the suggested design changes 
>were accepted
>by one of the co-authors of the draft".

The KISA authors contacted me immediately after your first message 
and my response. They seem to be comfortable with the changes that I 
agreed were good suggestions, ones that improved the design but did 
not fundamentally alter it.

>  At this time, the document is not yet a PKIX WG document and
>there is no WG decision about accepting or rejecting any design 
>change at this stage AFAIK.

As I noted i a prior message, I did give the KISA authors permission 
to post it as a PKIX I-D, without having conducted the poll that I 
had said would be conducted at the PKIX meeting in PHL. That's why I 
initiated a poll earlier this week, in response to your comments.

>  The last sentence of your response is inappropriate.

The last sentence of my response is accurate.  It reflects the fact 
that you, as a member of this WG, have rarely if ever been completely 
satisfied with any WG document and that the WG has, nonetheless, 
achieved consensus on numerous documents that have been published as 
RFCs. It also reflects that fact that in many of these instances, 
your requests for changes to documents have not been supported by 
other WG members, which is why they did not result in changes to the 
documents when they were issued as RFCs.

Steve

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Date: Thu, 3 Jul 2008 08:59:39 +0200
Sender: [email-masked]

------=_NextPart_08070308593621572577584_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Steve,

You are saying: "Some but not ALL of your suggested design changes were accepted".
The reality is :"Some but not ALL of the suggested design changes were accepted 
by one of the co-authors of the draft".

At this time, the document is not yet a PKIX WG document and 
there is no WG decision about accepting or rejecting any design change at this stage AFAIK.

The last sentence of your response is inappropriate.

Denis
----- Message reçu ----- 
De : Stephen Kent 
À : denis.pinkas 
Date : 2008-07-02, 15:41:07
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

At 2:11 PM +0200 7/2/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m62CBX9E005364
>
>Steve,
>
>In response to your question:
>
>Obviously, I am NOT in favor of it, since it appears that there is 
>no intent to pass major change controls to the WG.
>Authors may submit Informational RFCs without the support of the WG.
>
>Denis
>

Denis,

The authors will abide by the same rules as anyone who submits a 
document to a WG.

Some but not ALL of your suggested design changes were accepted. That 
hardly seems unreasonable at this stage of the discussion. If we 
rejected every I-D that had not incorporated EVERY change that you 
unilaterally proposed, I'm not sure that PKIK would have published 
any RFCs :-).

Steve

------=_NextPart_08070308593621572577584_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>Steve,</DIV>
<DIV>&nbsp;</DIV>
<DIV>You are saying: "Some but not ALL of your suggested design changes were 
accepted".</DIV>
<DIV>The reality is :"Some but not ALL of&nbsp;the suggested design changes were 
accepted <BR>by one of the co-authors of the draft".</DIV>
<DIV>&nbsp;</DIV>
<DIV>At this time, the document is not yet a PKIX WG document and <BR>there is 
no WG decision about accepting or rejecting any design change&nbsp;at this stage 
AFAIK.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The last sentence of&nbsp;your response&nbsp;is inappropriate.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal">----- 
  Message reçu ----- </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[email-masked]">Stephen Kent</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[email-masked]">denis.pinkas</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-07-02, 15:41:07</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Comments on draft-ietf-pkix-tac-00.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>At 2:11 PM +0200 7/2/08, Denis Pinkas wrote:<BR>&gt;Content-Type: 
  text/html<BR>&gt;X-MIME-Autoconverted: from 8bit to quoted-printable by 
  <BR>&gt;balder-227.proper.com id 
  m62CBX9E005364<BR>&gt;<BR>&gt;Steve,<BR>&gt;<BR>&gt;In response to your 
  question:<BR>&gt;<BR>&gt;Obviously, I am NOT in favor of it, since it appears 
  that there is <BR>&gt;no intent to pass major change controls to the 
  WG.<BR>&gt;Authors may submit Informational RFCs without the support of the 
  WG.<BR>&gt;<BR>&gt;Denis<BR>&gt;<BR><BR>Denis,<BR><BR>The authors will abide 
  by the same rules as anyone who submits a <BR>document to a WG.<BR><BR>Some 
  but not ALL of your suggested design changes were accepted. That <BR>hardly 
  seems unreasonable at this stage of the discussion. If we <BR>rejected every 
  I-D that had not incorporated EVERY change that you <BR>unilaterally proposed, 
  I'm not sure that PKIK would have published <BR>any RFCs 
  :-).<BR><BR>Steve<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070308593621572577584_002--

From: JasonPaul <[email-masked]>
To: [email-masked]
Subject: Are you good in bed
Date: Thu, 3 Jul 2008 02:16:05 -0400

--Boundary_(ID_wivCzIEJZZSki3yiIzTKFP)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Slam her till her juices flow and rock her till she moans and groans. http://www.manybest.com/

--Boundary_(ID_wivCzIEJZZSki3yiIzTKFP)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Slam her till her juices flow and rock her till she moans and groans.<div><a href="http://www.manybest.com/">http://www.manybest.com/</a></div></body></html>

--Boundary_(ID_wivCzIEJZZSki3yiIzTKFP)--

Content-class: urn:content-classes:message
Subject: RE: OCSP Agility
Date: Wed, 2 Jul 2008 17:27:51 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8DC8A.7BB723C7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The URL does not work.

=20

Unless there is something new, I do not see a need for this.

=20

The algorithms are dictated by the subject certificate.

=20

But, I will be happy to review a newer draft to see if offers any value.

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, July 02, 2008 4:04 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: OCSP Agility

=20

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument
for this draft is the same as that I made for Steven Farell's: If we
want systems to interoperate reliably we should have defined standards
for providing the necessary information and not rely on heuristic
kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01
.txt

=20

------_=_NextPart_001_01C8DC8A.7BB723C7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-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]-->
<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:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The URL does not =
work.<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'>Unless there is something new, I do =
not
see a need for this.<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'>The algorithms are dictated by the =
subject
certificate.<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'>But, I will be happy to review a =
newer
draft to see if offers any value.<o:p></o:p></span></font></p>

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span 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>Hallam-Baker, =
Phillip<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July 02, =
2008
4:04 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked];
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> OCSP =
Agility</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><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>I
would like to propose OCSP algorithm agility as a WG =
item.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>I
have updated the draft circulated earlier. Essentially the argument for =
this
draft is the same as that I made for Steven Farell's: If we want systems =
to
interoperate reliably we should have defined standards for providing the
necessary information and not rely on heuristic =
kludges.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><a
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagi=
lity-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-oc=
spagility-01.txt</a></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'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C8DC8A.7BB723C7--

Content-class: urn:content-classes:message
Subject: OCSP Agility
Date: Wed, 2 Jul 2008 13:04:07 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8DC7F.65A461C9
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument =
for this draft is the same as that I made for Steven Farell's: If we =
want systems to interoperate reliably we should have defined standards =
for providing the necessary information and not rely on heuristic =
kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.=
txt

=20

------_=_NextPart_001_01C8DC7F.65A461C9
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6001.18063" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<P><FONT face=3DArial size=3D2>I would like to propose OCSP algorithm =
agility as a WG item.</FONT></P>=0A=
<P><FONT face=3DArial size=3D2>I have updated the draft circulated =
earlier. Essentially the argument for this draft is the same as that I =
made for Steven Farell's: If we want systems to interoperate reliably we =
should have defined standards for providing the necessary information =
and not rely on heuristic kludges.</FONT></P>=0A=
<P><FONT face=3DArial size=3D2><A =
href=3D"http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagi=
lity-01.txt">http://www.ietf.org/proceedings/staging/draft-hallambaker-oc=
spagility-01.txt</A></FONT></P>=0A=
<DIV><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>
------_=_NextPart_001_01C8DC7F.65A461C9--

From: junior <[email-masked]>
To: [email-masked]
Subject: Enhance your love life now
Date: Thu, 3 Jul 2008 00:44:44 +0700

--Boundary_(ID_lycAaVJENBOxn0ruIsXVEE)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Women will tend to blow more now that you have a larger tool http://www.directmany.com/

--Boundary_(ID_lycAaVJENBOxn0ruIsXVEE)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Women will tend to blow more now that you have a larger tool<div><a href="http://www.directmany.com/">http://www.directmany.com/</a></div></body></html>

--Boundary_(ID_lycAaVJENBOxn0ruIsXVEE)--

Date: Wed, 2 Jul 2008 09:41:07 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: "ietf-pkix"<[email-masked]>
Sender: [email-masked]

At 2:11 PM +0200 7/2/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m62CBX9E005364
>
>Steve,
>
>In response to your question:
>
>Obviously,  I am NOT in favor of it, since it appears that there is 
>no intent to pass major change controls to the WG.
>Authors may submit Informational RFCs without the support of the WG.
>
>Denis
>

Denis,

The authors will abide by the same rules as anyone who submits a 
document to a WG.

Some but not ALL of your suggested design changes were accepted. That 
hardly seems unreasonable at this stage of the discussion. If we 
rejected every I-D that had not incorporated EVERY change that you 
unilaterally proposed, I'm not sure that PKIK would have published 
any RFCs :-).

Steve

Content-class: urn:content-classes:message
Subject: RE: "other certs" extension straw poll
Date: Wed, 2 Jul 2008 07:00:32 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8DC4C.48044B1B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes (to both)
=20
The fact that some people purport to be able to construct a heuristic =
kludge to address a problem is not a reason not to act.
=20
The problem with heuristic kludges is that they tend to be fragile and =
they tend to interact poorly with other systems. Most of all they are a =
barrier to interoperability which is what the standards process is all =
about.

________________________________

From: [email-masked] on behalf of Stephen Kent
Sent: Thu 6/19/2008 1:57 PM
To: [email-masked]
Subject: "other certs" extension straw poll

Folks,

Back in December, Stephen Farrell sent a message to PKIX noting a =
problem that had been identified in the W3C, and proposing a solution in =
the form of a proposed extension. He published an individual I-D at this =
time. There was a little discussion on the list about this proposal in =
January, (a total of about a dozen messages). Stephen made a =
presentation on his proposal at the Phildelphia meeting in March and in =
response to some of the comments he received, Stephen revised his =
proposal to include additional details.  There was agreement at the =
meeting that the discussion should be moved to the list, to determine of =
the work should proceed as a PKIX WG item, and if so, whether it would =
become experimental, standards track, or whatever.

The I-D, which was released at the 02 rev level after the meeting, =
triggered  additional discussion on the list that month, a total of 15 =
messages from a set of 5 individuals (including Stephen). Most of the =
messages in this thread were not supportive of the proposal for various =
reasons, e.g., argument about why one could not use the permanent =
identifier extension, or some other SAN, etc. I raised concerns about =
the lack of details for how an RP would use the data in this extension.

Stephen has asked that we conduct a straw poll on the topic of accepting =
this as a WG item.  I suggest that PKIX members review the current rev =
of the I-D (draft-farrell-pkix-other-certs-02.txt) and the messages from =
April, and then send a message to this list over the next two weeks.  =
(The straw poll will close on July 4.)

This poll is not deciding whether the I-D in its current form will be =
adopted, but rather whether the I-D addresses a problem that PKIX wants =
to address AND that the document provides a suitable basis to begin =
addressing the problem.

I request that poll responses be of the form:

        YES (to both questions)
        NO (to the first question)
        YES-BUT (yes to the first question, but NO to the second =
question)

Thanks,

Steve

------_=_NextPart_001_01C8DC4C.48044B1B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>"other certs" extension straw poll</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<STYLE type=3Dtext/css><!--=0A=
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }=0A=
 --></STYLE>=0A=
=0A=
<META content=3D"MSHTML 6.00.6001.18063" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText26008 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Yes (to =
both)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>The fact that some people =
purport to be able to construct a heuristic kludge to address a problem =
is not a reason not to act.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>The problem with heuristic =
kludges is that they tend to be fragile and they tend to interact poorly =
with other systems. Most of all they are a barrier to interoperability =
which is what the standards process is all about.</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =
on behalf of Stephen Kent<BR><B>Sent:</B> Thu 6/19/2008 1:57 =
PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> "other certs" =
extension straw poll<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<DIV>Folks,</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Back in December, Stephen Farrell sent a message to PKIX noting a =
problem that had been identified in the W3C, and proposing a solution in =
the form of a proposed extension. He published an individual I-D at this =
time. There was a little discussion on the list about this proposal in =
January, (a total of about a dozen messages). Stephen made a =
presentation on his proposal at the Phildelphia meeting in March and in =
response to some of the comments he received, Stephen revised his =
proposal to include additional details.&nbsp; There was agreement at the =
meeting that the discussion should be moved to the list, to determine of =
the work should proceed as a PKIX WG item, and if so, whether it would =
become experimental, standards track, or whatever.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>The I-D, which was released at the 02 rev level after the meeting, =
triggered&nbsp; additional discussion on the list that month, a total of =
15 messages from a set of 5 individuals (including Stephen). Most of the =
messages in this thread were not supportive of the proposal for various =
reasons, e.g., argument about why one could not use the permanent =
identifier extension, or some other SAN, etc. I raised concerns about =
the lack of details for how an RP would use the data in this =
extension.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Stephen has asked that we conduct a straw poll on the topic of =
accepting this as a WG item.&nbsp; I suggest that PKIX members review =
the current rev of the I-D (<FONT =
color=3D#ff0000>draft-farrell-pkix-other-certs-02.txt)</FONT> and the =
messages from April, and then send a message to this list over the next =
two weeks.&nbsp; (The straw poll will close on July 4.)</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>This poll is not deciding whether the I-D in its current form will =
be adopted, but rather whether the I-D addresses a problem that PKIX =
wants to address AND that the document provides a suitable basis to =
begin addressing the problem.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>I request that poll responses be of the form:</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; YES (to both =
questions)</DIV>=0A=
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NO (to the first =
question)</DIV>=0A=
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; YES-BUT (yes to the =
first question, but NO to the second question)</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Thanks,</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Steve</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV><BR></DIV></DIV></BODY></HTML>
------_=_NextPart_001_01C8DC4C.48044B1B--

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Date: Wed, 2 Jul 2008 14:11:18 +0200
Sender: [email-masked]

------=_NextPart_08070214111799157064155_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Steve,

In response to your question:

Obviously,  I am NOT in favor of it, since it appears that there is no intent to pass major change controls to the WG.
Authors may submit Informational RFCs without the support of the WG.

Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : denis.pinkas 
Date : 2008-07-01, 21:52:18
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

..
True. it is invisible to RPs.

Denis: "Greater security invisible to RPs" = no advantage for RPs = no advantage at all.

I disagree. Many claims made by a CA in a CP or CPS may not be externally verifiable by an RP, yet an RP may rely on them.

>If the draft goes along, I would see the place for two schemes:
>
>a) a simpler scheme without the split key and blind signing aspects
>of the design,
>b) a more complex scheme with the split key and blind signing
>aspects of the design.

This I-D is targeted as an informational RFC. As such it is
describing a proposed design for TACs, one that meets the
requirements perceived by the (primary) authors. There is room for a
second informational RFC describing an alternative design, one that
does not rely on slit key signing and (internal use of blind
signatures).

Denis: I guess that it is still up to the WG to decide whether
the PKIX WG would sponsor or not this draft.

You're right. I did give permission to post this as a PKIX document, targeted as an Informational RFC, before getting a sense of the WG on this.

So, let me ask now if there are objections to having PKIX adopt this as a document. Obviously I am in favor of it, else I would not have signed up as a co-author.

Steve

------=_NextPart_08070214111799157064155_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<STYLE type=text/css><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></STYLE>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>Steve,</DIV>
<DIV>&nbsp;</DIV>
<DIV>In response to your question:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Obviously, &nbsp;I am NOT in favor of it, since it appears that there is no 
intent to pass major change controls to the WG.</DIV>
<DIV>Authors may&nbsp;submit Informational RFCs without the support of the 
WG.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<DIV>----- Message reçu ----- </DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[email-masked]">owner-ietf-pkix</A> 
</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[email-masked]">denis.pinkas</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-07-01, 21:52:18</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Comments on draft-ietf-pkix-tac-00.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <BLOCKQUOTE cite="" type="cite">
    <BLOCKQUOTE>...<BR>True. it is invisible to RPs.</BLOCKQUOTE>
    <BLOCKQUOTE>&nbsp;</BLOCKQUOTE>
    <BLOCKQUOTE><B>Denis: "Greater security invisible to RPs" = no advantage 
      for RPs = no advantage at all.</B></BLOCKQUOTE></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>I disagree. Many claims made by a CA in a CP or CPS may not be externally 
  verifiable by an RP, yet an RP may rely on them.</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite="" type="cite">
    <BLOCKQUOTE><BR>&gt;If the draft goes along, I would see the place for two 
      schemes:<BR>&gt;<BR>&gt;a) a simpler scheme without the split key and 
      blind signing aspects<BR>&gt;of the design,<BR>&gt;b) a more complex 
      scheme with the split key and blind signing<BR>&gt;aspects of the 
      design.<BR><BR><BR>This I-D is targeted as an informational RFC. As such 
      it is<BR>describing a proposed design for TACs, one that meets 
      the<BR>requirements perceived by the (primary) authors. There is room for 
      a<BR>second informational RFC describing an alternative design, one 
      that<BR>does not rely on slit key signing and (internal use of 
      blind<BR>signatures).<BR></BLOCKQUOTE>
    <BLOCKQUOTE><B>Denis: I guess that it&nbsp;is still up to the WG to decide 
      whether</B></BLOCKQUOTE>
    <BLOCKQUOTE><B>the PKIX WG would sponsor or not this 
  draft.</B></BLOCKQUOTE></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>You're right. I did give permission to post this as a PKIX document, 
  targeted as an Informational RFC, before getting a sense of the WG on 
  this.</DIV>
  <DIV><BR></DIV>
  <DIV>So, let me ask now if there are objections to having PKIX adopt this as a 
  document. Obviously I am in favor of it, else I would not have signed up as a 
  co-author.</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070214111799157064155_002--

Date: Tue, 1 Jul 2008 15:52:18 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: "ietf-pkix"<[email-masked]>
Sender: [email-masked]

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

>...
>True. it is invisible to RPs.
>
>Denis: "Greater security invisible to RPs" = no advantage for RPs = 
>no advantage at all.

I disagree. Many claims made by a CA in a CP or CPS may not be 
externally verifiable by an RP, yet an RP may rely on them.

>
>>If the draft goes along, I would see the place for two schemes:
>>
>>a) a simpler scheme without the split key and blind signing aspects
>>of the design,
>>b) a more complex scheme with the split key and blind signing
>>aspects of the design.
>
>
>This I-D is targeted as an informational RFC. As such it is
>describing a proposed design for TACs, one that meets the
>requirements perceived by the (primary) authors. There is room for a
>second informational RFC describing an alternative design, one that
>does not rely on slit key signing and (internal use of blind
>signatures).
>
>Denis: I guess that it is still up to the WG to decide whether
>the PKIX WG would sponsor or not this draft.

You're right. I did give permission to post this as a PKIX document, 
targeted as an Informational RFC, before getting a sense of the WG on 
this.

So, let me ask now if there are objections to having PKIX adopt this 
as a document. Obviously I am in favor of it, else I would not have 
signed up as a co-author.

Steve
--============_-997180555==_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: Comments on
draft-ietf-pkix-tac-00.txt</title></head><body>
<blockquote type="cite" cite>
<blockquote>...<br>
True. it is invisible to RPs.</blockquote>
<blockquote>&nbsp;</blockquote>
<blockquote><b>Denis: &quot;Greater security invisible to RPs&quot; =
no advantage for RPs = no advantage at all.</b></blockquote>
</blockquote>
<div><br></div>
<div>I disagree. Many claims made by a CA in a CP or CPS may not be
externally verifiable by an RP, yet an RP may rely on them.</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote><br>
&gt;If the draft goes along, I would see the place for two
schemes:<br>
&gt;<br>
&gt;a) a simpler scheme without the split key and blind signing
aspects<br>
&gt;of the design,<br>
&gt;b) a more complex scheme with the split key and blind signing<br>
&gt;aspects of the design.<br>
<br>
<br>
This I-D is targeted as an informational RFC. As such it is<br>
describing a proposed design for TACs, one that meets the<br>
requirements perceived by the (primary) authors. There is room for
a<br>
second informational RFC describing an alternative design, one
that<br>
does not rely on slit key signing and (internal use of blind<br>
signatures).<br>
</blockquote>
<blockquote><b>Denis: I guess that it&nbsp;is still up to the WG to
decide whether</b></blockquote>
<blockquote><b>the PKIX WG would sponsor or not this
draft.</b></blockquote>
</blockquote>
<div><br></div>
<div>You're right. I did give permission to post this as a PKIX
document, targeted as an Informational RFC, before getting a sense of
the WG on this.</div>
<div><br></div>
<div>So, let me ask now if there are objections to having PKIX adopt
this as a document. Obviously I am in favor of it, else I would not
have signed up as a co-author.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-997180555==_ma============--

Content-class: urn:content-classes:message
Subject: RE: Name constraint question
Date: Tue, 1 Jul 2008 15:20:18 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Tony Bartoletti" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Does anyone see similar pitfalls in DN (Geopolitical or dc component
based) based names?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tony Bartoletti
Sent: Tuesday, July 01, 2008 3:06 PM
To: [email-masked]
Subject: Re: Name constraint question

This thread is taking on a delightful "Alice Through the Looking=20
Glass" quality...

I am reminded of a phrase my uncle would sometimes employ:

   "LOOK!" said the blind man, to his deaf son,
    as they walked off the edge of the cliff...

____tony____

Date: Tue, 01 Jul 2008 12:05:47 -0700
To: [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: Name constraint question
Sender: [email-masked]

This thread is taking on a delightful "Alice Through the Looking 
Glass" quality...

I am reminded of a phrase my uncle would sometimes employ:

   "LOOK!" said the blind man, to his deaf son,
    as they walked off the edge of the cliff...

____tony____

Date: Tue, 1 Jul 2008 12:22:50 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Name constraint question
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 3:07 AM +1200 7/2/08, Peter Gutmann wrote:
>Stephen Kent <[email-masked]> writes:
>
>>Name constraints checking does not imply any form of external validation on
>>the "validity" of the name, for any type of name. The purpose of the
>>extension is to constrain the range of names asserted in subordinate certs,
>>not to ensure that the names are "valid" in some larger context. It could be
>>very difficult to establish validity for many types of names.  For example,
>>if a DNS name does not resolve for me, does that make it invalid?  Is it more
>>valid if resolved using DNESEC vs. vanilla DNS? What if the IP address
>>returned is not reachable, at the time I check it, ...?
>
>But the checking rules require parsing URIs in order to apply the checks.
>Here's an example of a malformed URI being used to avoid name constraints:
>
>CA cert: excluded subtree, example.com
>Subject cert, altName: ftp:/example.com
>
>(non-matched as "ftp:/example.com", processed as FTP -> "example.com").  If
>it's OK to have syntactically invalid URIs then this (and a million variants)
>can be used to escape excluded subtrees, thus making them essentially useless
>(actually you can already do that with character-set encoding tricks and
>whatnot so excluded subtrees have always been a no-hoper for security
>purposes, I'll bet no implementation in existance can catch even the most
>basic trick like using "ex%41mple.com", let alone "ex%u0041mple.com",
>"ex&#x41;mple.com", or "ex%EF%BC%A1mpple.com").
>
>Maybe the RFC should simply deprecate excluded subtrees to avoid giving RPs
>the erroneous impression that they're effective for anything.
>
>Peter.

Peter,

Sorry that I misunderstood your use of the term "valid" here. I agree 
with you that any name form that is used in the name constraints 
extension MUST be syntactically valid.

Steve

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Name constraint question
Cc: [email-masked]
Date: Wed, 02 Jul 2008 03:07:15 +1200
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>Name constraints checking does not imply any form of external validation on
>the "validity" of the name, for any type of name. The purpose of the
>extension is to constrain the range of names asserted in subordinate certs,
>not to ensure that the names are "valid" in some larger context. It could be
>very difficult to establish validity for many types of names.  For example,
>if a DNS name does not resolve for me, does that make it invalid?  Is it more
>valid if resolved using DNESEC vs. vanilla DNS? What if the IP address
>returned is not reachable, at the time I check it, ...?

But the checking rules require parsing URIs in order to apply the checks.
Here's an example of a malformed URI being used to avoid name constraints:

CA cert: excluded subtree, example.com
Subject cert, altName: ftp:/example.com

(non-matched as "ftp:/example.com", processed as FTP -> "example.com").  If
it's OK to have syntactically invalid URIs then this (and a million variants)
can be used to escape excluded subtrees, thus making them essentially useless
(actually you can already do that with character-set encoding tricks and
whatnot so excluded subtrees have always been a no-hoper for security
purposes, I'll bet no implementation in existance can catch even the most
basic trick like using "ex%41mple.com", let alone "ex%u0041mple.com",
"ex&#x41;mple.com", or "ex%EF%BC%A1mpple.com").

Maybe the RFC should simply deprecate excluded subtrees to avoid giving RPs
the erroneous impression that they're effective for anything.

Peter.

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Date: Tue, 1 Jul 2008 16:44:00 +0200
Sender: [email-masked]

------=_NextPart_08070116435996456817355_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Comments in line.
----- Message reçu ----- 
De : Stephen Kent 
À : denis.pinkas 
Date : 2008-07-01, 16:01:34
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

At 12:02 PM +0200 7/1/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m61A2c5J025564
>
>Steve,
>
>It looks like the main motivation is to (finally) find an 
>application for the split key and blind signing mechanism.
>:-)
>The crypto security should be not the central point.

I think it's fair to say that these crypto security mechanisms (split 
key signing and blind signatures) offer greater security than what is 
available from relying only on procedural security promises.

> There is no way proposed in the draft so that a RP can know that 
>the split key and blind signing aspects occurred or not.

True. it is invisible to RPs.

Denis: "Greater security invisible to RPs" = no advantage for RPs = no advantage at all.

>If the draft goes along, I would see the place for two schemes:
>
>a) a simpler scheme without the split key and blind signing aspects 
>of the design,
>b) a more complex scheme with the split key and blind signing 
>aspects of the design.

This I-D is targeted as an informational RFC. As such it is 
describing a proposed design for TACs, one that meets the 
requirements perceived by the (primary) authors. There is room for a 
second informational RFC describing an alternative design, one that 
does not rely on slit key signing and (internal use of blind 
signatures).

Denis: I guess that it is still up to the WG to decide whether 
the PKIX WG would sponsor or not this draft.

Steve

------=_NextPart_08070116435996456817355_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>Comments in line.</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal">----- 
  Message reçu ----- </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[email-masked]">Stephen Kent</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[email-masked]">denis.pinkas</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-07-01, 16:01:34</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Comments on draft-ietf-pkix-tac-00.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>At 12:02 PM +0200 7/1/08, Denis Pinkas wrote:<BR>&gt;Content-Type: 
  text/html<BR>&gt;X-MIME-Autoconverted: from 8bit to quoted-printable by 
  <BR>&gt;balder-227.proper.com id 
  m61A2c5J025564<BR>&gt;<BR>&gt;Steve,<BR>&gt;<BR>&gt;It looks like the main 
  motivation is to (finally) find an <BR>&gt;application for the split key and 
  blind signing mechanism.<BR>&gt;:-)<BR>&gt;The crypto security should be not 
  the central point.<BR><BR>I think it's fair to say that these crypto security 
  mechanisms (split <BR>key signing and blind signatures) offer greater security 
  than what is <BR>available from relying only on procedural security 
  promises.<BR><BR>&gt; There is no way proposed in the draft so that a RP can 
  know that <BR>&gt;the split key and blind signing aspects occurred or 
  not.<BR><BR>True. it is invisible to RPs.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><STRONG>Denis: "Greater security invisible to RPs" = no advantage for RPs 
  = no advantage at all.</STRONG></DIV>
  <DIV><BR>&gt;If the draft goes along, I would see the place for two 
  schemes:<BR>&gt;<BR>&gt;a) a simpler scheme without the split key and blind 
  signing aspects <BR>&gt;of the design,<BR>&gt;b) a more complex scheme with 
  the split key and blind signing <BR>&gt;aspects of the design.<BR><BR><BR>This 
  I-D is targeted as an informational RFC. As such it is <BR>describing a 
  proposed design for TACs, one that meets the <BR>requirements perceived by the 
  (primary) authors. There is room for a <BR>second informational RFC describing 
  an alternative design, one that <BR>does not rely on slit key signing and 
  (internal use of blind <BR>signatures).<BR></DIV>
  <DIV><STRONG>Denis: I guess that it&nbsp;is still up to the WG to decide 
  whether <BR>the PKIX WG would sponsor or not this draft.</STRONG></DIV>
  <DIV><BR>Steve<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070116435996456817355_002--

Date: Tue, 1 Jul 2008 10:19:05 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Name constraint question
Cc: [email-masked]
Sender: [email-masked]

At 11:21 PM +1200 7/1/08, Peter Gutmann wrote:
>Here's one: Say an issuing cert contains a name constraint for (just for
>argument's sake) a URI, and the subject cert contais a URI.  The issuer cert's
>URI is invalid.  Alternatively, the subject cert's URI is invalid.
>
>What should happen?  Is the output for the check true or false?
>
>NB: Just because a URI is malformed doesn't mean that the relying party
>software won't accept it, there's so much broken stuff out there that much web
>software bends over backwards to interpret almost anything URI-like.  So
>saying "the RP should reject it" won't work, the cert processing software has
>to make the decision.
>
>Peter.

Peter,

Name constraints checking does not imply any form of external 
validation on the "validity" of the name, for any type of name. The 
purpose of the extension  is to constrain the range of names asserted 
in subordinate certs, not to ensure that the names are "valid" in 
some larger context. It could be very difficult to establish validity 
for many types of names.  For example, if a DNS name does not resolve 
for me, does that make it invalid?  Is it more valid if resolved 
using DNESEC vs. vanilla DNS? What if the IP address returned is not 
reachable, at the time I check it, ...?

Steve

Date: Tue, 1 Jul 2008 10:01:34 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Cc: "ietf-pkix"<[email-masked]>
Sender: [email-masked]

At 12:02 PM +0200 7/1/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m61A2c5J025564
>
>Steve,
>
>It looks like the main motivation is to (finally) find an 
>application for the split key and blind signing mechanism.
>:-)
>The crypto security should be not the central point.

I think it's fair to say that these crypto security mechanisms (split 
key signing and blind signatures) offer greater security than what is 
available from relying only on procedural security promises.

>  There is no way proposed in the draft so that a RP can know that 
>the split key and blind signing aspects occurred or not.

True. it is invisible to RPs.

>If the draft goes along, I would see the place for two schemes:
>
>a) a simpler scheme without the split key and blind signing aspects 
>of the design,
>b) a more complex scheme with the split key and blind signing 
>aspects of the design.
>

This I-D is targeted as an informational RFC.  As such it is 
describing a proposed design for TACs, one that meets the 
requirements perceived by the (primary) authors. There is room for a 
second informational RFC describing an alternative design, one that 
does not rely on slit key signing and (internal use of blind 
signatures).

Steve

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Name constraint question
Date: Tue, 01 Jul 2008 23:21:15 +1200
Sender: [email-masked]

Here's one: Say an issuing cert contains a name constraint for (just for
argument's sake) a URI, and the subject cert contais a URI.  The issuer cert's
URI is invalid.  Alternatively, the subject cert's URI is invalid.

What should happen?  Is the output for the check true or false?

NB: Just because a URI is malformed doesn't mean that the relying party
software won't accept it, there's so much broken stuff out there that much web
software bends over backwards to interpret almost anything URI-like.  So
saying "the RP should reject it" won't work, the cert processing software has
to make the decision.

Peter.

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
Date: Tue, 1 Jul 2008 12:02:25 +0200
Sender: [email-masked]

------=_NextPart_08070112021622587804571_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Steve,

It looks like the main motivation is to (finally) find an application for the split key and blind signing mechanism. 
:-)
The crypto security should be not the central point. 

There is no way proposed in the draft so that a RP can know that the split key and blind signing aspects occurred or not.

If the draft goes along, I would see the place for two schemes:

a) a simpler scheme without the split key and blind signing aspects of the design, 
b) a more complex scheme with the split key and blind signing aspects of the design.

Scheme a) is simpler to implement. 

In any case, the RP should be able to know which scheme was used, keeping in mind the limitation: 
the CA could lie in any case.

Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : denis.pinkas 
Date : 2008-06-30, 19:43:58
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

Denis,
..
Denis :  in the above exchanges, the RA does not know the pseudonym. The mapping is only done using the UserKey.
The threshold signature and blind signature elements are not fundamental.
Sorry that I misread your text, inferring that the RA supplied the pseudonym. Although my comment about the source of the pseudonym wa wrong, it doesn't change my conclusion (see below).

The next part of your proposed redesign is as follows:

If the UserKey is not in the cache of the CA, the request is rejected.
If the pseudonym is not unique, the request is rejected and the CA proposes a different pseudonym.
In that case, the entity makes a second request with the same UserKey. Otherwise the CA contacts the RA
to make sure that the registration information kept by the RA will not be deleted, generates the PKC
and sends it back to the entity.

In that case, the CA maintains a database which contains:

- the UserKey chosen by the RA,
- the PKC issued to the entity.

In the design you propose, the CA issued the cert to the user by itself (from a crypto perspective), which undermines the two-party issuance model in the I-D. The split signing key procedure described in the I-D requires that the RA also sign the hash of the cert, which prevents the CA from acting unilaterally (which would yield a non-traceable cert). Having both the CA and RA sign the cert yields a stronger system, and the blind signature by the CA is needed to enable the split key signing without disclosing the hash value to the RA.

So, unless one wants to weaken the guarantees provided by the two-party signing, I think the split key and blind signing aspects of the design need to be retained.  Also, as I noted earlier given the split key and blind signature aspects of the design in the I-D, the terms AI and BI are appropriate.

I agree that if one did not want to have the crypto security offered by the split key approach (which then necessitates the blind signature function), the design here could be simplified. But, my co-authors see this form of crypto security as a central, motivating aspect of the design, so I believe it should remain.  Thanks, though, for your suggestions re inclusion of a time stamp in the Token and the timeout notion to help with garbage collection.

Steve

------=_NextPart_08070112021622587804571_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<STYLE type=text/css><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></STYLE>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>Steve,</DIV>
<DIV>&nbsp;</DIV>
<DIV>It looks like the main motivation is to&nbsp;(finally) find an application 
for the split key and blind signing mechanism. </DIV>
<DIV>:-)</DIV>
<DIV>The crypto security should be&nbsp;not the central point. </DIV>
<DIV>&nbsp;</DIV>
<DIV>There is no way proposed in the draft so that a RP can know that the split 
key and blind signing aspects occurred or not.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If the draft goes along, I would see the place for two schemes:</DIV>
<DIV>&nbsp;</DIV>
<DIV>a) a simpler scheme without the split key and blind signing aspects of the 
design, </DIV>
<DIV>b) a more complex scheme with the split key and blind signing aspects of 
the design.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Scheme a) is simpler to implement.&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>In any case, the RP should be able to know which scheme was used, keeping 
in mind the limitation:&nbsp;<BR>the CA could lie in any case.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis<BR></DIV>
<DIV>----- Message reçu ----- </DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[email-masked]">owner-ietf-pkix</A> 
</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[email-masked]">denis.pinkas</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-06-30, 19:43:58</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Comments on draft-ietf-pkix-tac-00.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>Denis,</DIV>
  <DIV>...</DIV>
  <BLOCKQUOTE cite="" type="cite">
    <BLOCKQUOTE><B>Denis&nbsp;: &nbsp;in the above&nbsp;exchanges, the RA does 
      not know the pseudonym. The mapping is only done using the UserKey.<BR>The 
      threshold signature and blind signature elements are not 
    fundamental.</B></BLOCKQUOTE></BLOCKQUOTE>
  <DIV>Sorry that I misread your text, inferring that the RA supplied the 
  pseudonym. Although my comment about the source of the pseudonym wa wrong, it 
  doesn't change my conclusion (see below).</DIV>
  <DIV><BR></DIV>
  <DIV>The next part of your proposed redesign is as follows:</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite="" type="cite">If the UserKey is not in the cache of the 
    CA, the request is rejected.</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">If the pseudonym is not unique, the request 
    is rejected and the CA proposes a different pseudonym.</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">In that case, the entity makes a second 
    request with the same UserKey. Otherwise the CA contacts the RA</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">to make sure that the registration 
    information kept by the RA will not be deleted, generates the PKC</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">and sends it back to the entity.</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite"><BR></BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">In that case, the CA maintains a database 
    which contains:</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite"><BR></BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">- the UserKey chosen by the RA,</BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">- the PKC issued to the entity.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>In the design you propose, the CA issued the cert to the user by itself 
  (from a crypto perspective), which undermines the two-party issuance model in 
  the I-D. The split signing key procedure described in the I-D requires that 
  the RA also sign the hash of the cert, which prevents the CA from acting 
  unilaterally (which would yield a non-traceable cert). Having both the CA and 
  RA sign the cert yields a stronger system, and the blind signature by the CA 
  is needed to enable the split key signing without disclosing the hash value to 
  the RA.</DIV>
  <DIV><BR></DIV>
  <DIV>So, unless one wants to weaken the guarantees provided by the two-party 
  signing, I think the split key and blind signing aspects of the design need to 
  be retained.&nbsp; Also, as I noted earlier given the split key and blind 
  signature aspects of the design in the I-D, the terms AI and BI are 
  appropriate.</DIV>
  <DIV><BR></DIV>
  <DIV>I agree that if one did not want to have the crypto security offered by 
  the split key approach (which then necessitates the blind signature function), 
  the design here could be simplified. But, my co-authors see this form of 
  crypto security as a central, motivating aspect of the design, so I believe it 
  should remain.&nbsp; Thanks, though, for your suggestions re inclusion of a 
  time stamp in the Token and the timeout notion to help with garbage 
  collection.</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08070112021622587804571_002--